gdb remote debugging - program crashes when stepping into a shared library

1.8k views Asked by At

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.

2

There are 2 answers

3
Pierre Guilbert On

Try to compile the shared library with the debugs flags.

1
user611775 On

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.