how to setup breakpoint in gdb with shared library function - gdb

I have problem with gdb, it wasn't stop in one function. Can you explain why and how to stop program after calling strcpy?
grzes#trampek:~/poligon$ gdb ./char_array2
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/grzes/poligon/char_array2...done.
(gdb) list
1 #include <stdio.h>
2 #include <string.h>
3
4 int main() {
5 char str_a[20];
6 printf("ssss");
7 strcpy(str_a, "Hello, world!\n");
8 printf(str_a);
9 }
10
(gdb) break main
Breakpoint 1 at 0x8048465: file char_array2.c, line 4.
(gdb) run
Starting program: /home/grzes/poligon/char_array2
Breakpoint 1, main () at char_array2.c:4
4 int main() {
(gdb) break strcpy
Breakpoint 2 at 0x1a1205
(gdb) cont
Continuing.
ssssHello, world!
Program exited with code 016.
(gdb) q
grzes#trampek:~/poligon$

You may be using gcc's __builtin_strcpy. Compile with gcc -fno-builtin and see if that helps.
For more info see: http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/C-Dialect-Options.html#C-Dialect-Options

Related

schedBreak(<tick>) gdb debugging function not working

I am trying to create breakpoints and debug gem5 using gdb. I referred to http://www.gem5.org/Debugger_Based_Debugging.
As in the official documentation in the above link, I tried `call schedBreak() but it doesn't work. the following are the full commands:
➜ test-gem5-x86 git:(master) ✗ gdb --args ./build/X86/gem5.opt configs/learning_gem5/part1/simple.py
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./build/X86/gem5.opt...done.
(gdb) b main
Breakpoint 1 at 0x4b0d20: main. (4 locations)
(gdb) run
Starting program: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffdef8) at build/X86/sim/main.cc:42
42 {
(gdb) call schedBreak(10000)
warn: need to stop all queues
(gdb) c
Continuing.
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.
gem5 compiled Aug 26 2019 20:59:02
gem5 started Sep 8 2019 15:17:55
gem5 executing on nirmal-cadsl2, pid 30158
command line: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
Global frequency set at 1000000000000 ticks per second
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes)
0: system.remote_gdb: listening for remote gdb on port 7001
Beginning simulation!
info: Entering event queue # 0. Starting simulation...
Hello world!
Exiting # tick 501393000 because exiting with last active thread context
[Inferior 1 (process 30158) exited normally]
(gdb)
While this other tutorial http://gem5.org/wiki/images/0/0e/ASPLOS2017_gem5_tutorial.pdf (assuming the debug function is not particular to ISA) tells me that the function is actually schedBreakCycle(), it gives me this No symbol "schedBreakCycle" in current context. The full commands shown below.
➜ test-gem5-x86 git:(master) ✗ gdb --args ./build/X86/gem5.opt configs/learning_gem5/part1/simple.py
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./build/X86/gem5.opt...done.
(gdb) b main
Breakpoint 1 at 0x4b0d20: main. (4 locations)
(gdb) run
Starting program: /home/hari/test-gem5-x86/build/X86/gem5.opt configs/learning_gem5/part1/simple.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffdef8) at build/X86/sim/main.cc:42
42 {
(gdb) call schedBreakCycle(10000)
No symbol "schedBreakCycle" in current context.
(gdb)
gem5 version: ea8c435b6c6c092d72047eee50f125f5ae7347c3
gdb version: GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Also, if I want to debug ALPHA or ARM full system on my ubuntu 18.04(x86), do I have to use any cross-compiled gdb versions or would native gdb suffice?
The tutorial is correct, you have to pass --debug-break to gem5:
gdb --args gem5.debug --debug-break=1000 ...
and then without breaking at main:
run
call schedBreak(5000)
continue
--debug-break generates a break at time 1000 and makes GDB stop there after main, and from that point, schedBreak does work.
Or alternatively first go to:
tbreak doSimLoop
run
call schedBreak(5000)
continue
schedBreak schedules an event in the event queue, which cannot be ready at main.
The breaks work by raising a signal, which GDB stops at by default.
ALPHA and ARM won't make a difference since schedBreak is a tiny helper to debug the host emulator itself, which is likely an x86 program. To debug the guest code, which is what most people want, see e.g. this tutorial.
Tested gem5 master at e87a293d1ffa6da38ba8fa145e7dc5128138ab77 in an X86 debug build.

gdb of simple hello world program not working as expected on Mac 10.13.6

I was just intending to explore the features of gdb by following:
https://www.youtube.com/watch?v=PorfLSr3DDI&t=212s
While trying to replicate the steps as in the movie above, I got slightly different output:
When I ran
gdb a.out
, I got this:
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 5 user staff 160 May 8 22:46 .
This is free software: you are free to change and redistribute it.wxr-xr-x 1 user staff 8432 May 8 22:46 a.out
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.world.c
This GDB was configured as "x86_64-apple-darwin17.7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
Users-MBP:codecompre_tooltest user$
For help, type "help".ooltest user$
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...
warning: dsym file UUID doesn't match the one in /Users/user/Documents/codecompre_tooltest/a.out
(no debugging symbols found)...done.
(gdb) start
Temporary breakpoint 1 at 0x100000f04
Starting program: /Users/user/Documents/codecompre_tooltest/a.out
[New Thread 0x1703 of process 1645]
[New Thread 0x1903 of process 1645]
[New Thread 0x1a03 of process 1645]
[3]+ Stopped gdb a.out
Why is this so, and how can I solve this?
NOTE: I have followed all the steps in:
http://panks.me/posts/2013/11/install-gdb-on-os-x-mavericks-from-source/
https://gist.github.com/kpy3/27014703672ad6d54c00dfc06e45f1ae

On Raspberry Pi, cross compile helloworld in x86 with native gdb doesn't show source info

When I cross compile the helloworld code on x86 target raspberry pi, the pi's native gdb doesn't show the symbol info. Native pi's gcc works fine.
Cross compiler:
gcc version 4.8.3 20140106 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.01 - Linaro GCC 2013.11)
Native Compiler:
gcc version 4.6.3 (Debian 4.6.3-14+rpi1)
ls -al hellow*
-rw-rw-r-- 1 pi pi 81 Nov 16 18:54 hellow.c
-rwxrwxr-x 1 pi pi 7080 Nov 16 18:54 hellow_cross_compile
-rwxr-xr-x 1 pi pi 6529 Nov 16 18:57 hellow_native_compile
tlee#raspberrypi ~/mnt/u1404/k_pi/hellow $ gdb hellow_cross_compile
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/tlee/mnt/u1404/k_pi/hellow/hellow_cross_compile...done.
(gdb) b main
Breakpoint 1 at 0x8414
(gdb) r
Starting program: /home/tlee/mnt/u1404/k_pi/hellow/hellow_cross_compile
Breakpoint 1, 0x00008414 in main ()
(gdb) quit
A debugging session is active.
Inferior 1 [process 21284] will be killed.
Quit anyway? (y or n) y
tlee#raspberrypi ~/mnt/u1404/k_pi/hellow $ gdb ./hellow_native_compile
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/tlee/mnt/u1404/k_pi/hellow/hellow_native_compile...done.
(gdb) b main
Breakpoint 1 at 0x83dc: file hellow.c, line 6.
(gdb) r
Starting program: /home/tlee/mnt/u1404/k_pi/hellow/hellow_native_compile
Breakpoint 1, main (argc=1, argv=0x7efff7e4) at hellow.c:6
6 printf("hellow\n");
(gdb) quit
A debugging session is active.
Inferior 1 [process 21307] will be killed.
Quit anyway? (y or n) y
Have anyone encounter this before? Any idea why and how to fix it?

gdb: how to set a breakpoint in a file with spaces

How does one set a breakpoint in a file that has a space in its filename or path?
It seems like this is not possible with GDB or am I missing something?
/tmp$ g++ -g debugee\ space.cpp
/tmp$ gdb ./a.out
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /tmp/a.out...done.
(gdb) break "/tmp/debugee space.cpp:4"
Breakpoint 1 at 0x4007e3: file debugee space.cpp, line 4.
(gdb) break "/tmp/debugee space.cpp":4
Note: breakpoint 1 also set at pc 0x4007e3.
Breakpoint 2 at 0x4007e3: file debugee space.cpp, line 4.
(gdb) run
Starting program: /tmp/a.out
Error in re-setting breakpoint 1: Function "/tmp/debugee space.cpp:4" not defined.
Error in re-setting breakpoint 2: Function "/tmp/debugee space.cpp:4" not defined.
Hello, world!
[Inferior 1 (process 14188) exited normally]
(gdb)
To me this looks like a regression in gdb 7.4. I reported the bug: http://sourceware.org/bugzilla/show_bug.cgi?id=13798
works for me (tm), didn't try with c++ though...
cat space\ spaces.c
#include <stdio.h>
int tmp(void) {
int a = 42;
printf("%d", a);
}
int main(void) {
tmp();
return 0;
}
$ gdb -q a.out
Reading symbols from /home/user/slask/gdb/a.out...done.
(gdb) b "space spaces.c":5
Breakpoint 1 at 0x4004f3: file space spaces.c, line 5.
(gdb) i b
Num Type Disp Enb Address What
1 breakpoint keep y 0x00000000004004f3 in tmp at space spaces.c:5
(gdb) run
Starting program: /home/user/slask/gdb/a.out
Breakpoint 1, tmp () at space spaces.c:5
5 printf("%d", a);
(gdb)

D2 and gdb issue

Short question: Is there any support of D2 in gdb (I have gdb 7.2) ?
Long story: I compiled next little application ...
// file main.d
int glVar = 0xAAAAAAAA;
void main()
{
glVar = 0xBBBBBBBB;
}
... using command "dmd -gc -debug main.d";
then I load it to gdb and trying to debug it:
vnm#vnm:~/proj/d_gdb_test$ gdb main
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/vnm/proj/d_gbb_test/main...done.
(gdb) b main
Breakpoint 1 at 0x804b667
(gdb) r
Starting program: /home/vnm/proj/d_gbb_test/main
[Thread debugging using libthread_db enabled]
Breakpoint 1, 0x0804b667 in main ()
(gdb) info line
No line number information available.
(gdb) info variables glVar
All variables matching regular expression "glVar":
File main.d:
int _D4main5glVari;
Why gdb can't show line information and why it shows symbols in mangled form ? Is this software issues or I'm doing something wrong ?
gdb has support for D starting with version 7.2. So, you can debug D programs with gdb 7.2.
Now, that doesn't mean that support is perfect - far from it in fact. For instance, I'm not sure that you can get it to print strings properly. And it's not at all surprising if it doesn't demangle D symbols. So, it works, but it's far from perfect.