开发者

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.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜