gdb remote debugging - program crashes when stepping into a shared library
I cross compiled a linux targeted app on a cygwin host. The program runs ok on the target and also with gdbserver. However, when I try to step through the program it crashes whenever I step into a shared library function. The backtrace gdb prints is:
(gdb) bt
#0 0x00000000004008f4 in ?? ()
#1 0x0000003f0380d7e4 in ?? ()
#2 0x00002b1373630000 in ?? ()
#3 0x00002b1373630590 in ?? ()
#4 0x00002b1373631348 in ?? ()
#5 0x00002b1373631888 in ?? ()
#6 0x0000003f03a1c510 in ?? ()
#7 0x0000000000000000 in ?? ()
If I set a breakpoint on the function and continues it doesn't crash.
This is hello.c:
void foo(int*);
int main()
{
int a;
foo(&a);
return a;
}
compiled with x86_64-unknown-linux-gnu-gcc -g -c hello.c.
and foo.c:
void foo(int *i)
{
*i = 2;
}
compiled with x86_64-unknown-linux-gnu-gcc -g -shared -Wl,-soname,libfoo.so -o libfoo.so foo.c.
The linking is with x86_64-开发者_运维知识库unknown-linux-gnu-gcc -Wl,-rpath,. libfoo.so hello.o -o hello.
I too have seen such situations, though it does not seem reproducible with your example (then again, I did not cross-compile). Nevertheless, hints for dealing with such situations...
- First of all of course, compilation with
-O0 -ggdb3
(not just -g) is advised. - Use
LD_BIND_NOW=1 gdb hello
to disable such lazy resolution. - If that did not help, use
b foo
in gdb and then single-step and/or continue as usual and wait for it to stop in foo.
Try to compile the shared library with the debugs flags.
精彩评论