当main.elf动态链接时，无法使用GDB分析核心转储(使用共享库)

Question

我正在尝试分析核心转储，但我得到了以下结果。

如果我让main.elf静态链接，一切都是正常的，我可以看到所有线程的bt。有什么想法吗？

GNU gdb 6.6.0.20070423-cvs
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=mipsel-linux --target=mipsel-linux-uclibc".
(gdb) file main.elf 
Reading symbols from /home/tobi/main.elf...Reading symbols from /home/tobi/main.dbg...done.
done.
(gdb) core-file /srv/tobi/core
warning: .dynamic section for "/lib/libpthread.so.0" is not at the expected address (wrong library or version mismatch?)
Error while mapping shared library sections:
/lib/libdl.so.0: No such file or directory.
Error while mapping shared library sections:
/lib/librt.so.0: No such file or directory.
Error while mapping shared library sections:
/lib/libm.so.0: No such file or directory.
Error while mapping shared library sections:
/lib/libstdc++.so.6: No such file or directory.
Error while mapping shared library sections:
/lib/libc.so.0: No such file or directory.
warning: .dynamic section for "/lib/libgcc_s.so.1" is not at the expected address (wrong library or version mismatch?)
Error while mapping shared library sections:
/lib/ld-uClibc.so.0: No such file or directory.
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Symbol file not found for /lib/libdl.so.0
Symbol file not found for /lib/librt.so.0
Symbol file not found for /lib/libm.so.0
Symbol file not found for /lib/libstdc++.so.6
Symbol file not found for /lib/libc.so.0
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Symbol file not found for /lib/ld-uClibc.so.0
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Core was generated by 'root/main.elf'.
Program terminated with signal 11, Segmentation fault.
#0  0x0046006c in NullPtr (parse_p=0x2ac9dc80, result_sym_p=0x13e3d6c "") at folder/my1.c:1624
1624      *ptr += 13;
(gdb) bt
#0  0x0046006c in NullPtr (parse_p=0x2ac9dc80, result_sym_p=0x13e3d6c "") at folder/my1.c:1624
#1  0x0047a31c in fn1 (line_ptr=0x2ac9dd18 "ccore_null_pointer", target_ptr=0x13e3d6c "", result_ptr=0x2ac9dd14) at folder/my2.c:980
#2  0x0047b9d0 in fn2 (macro_ptr=0x0, rtn_exp_ptr=0x0) at folder/my3.c:1483
/... some functions .../
#8  0x2aab7f9c in __nptl_setxid () from /lib/libpthread.so.0
Backtrace stopped: frame did not save the PC
(gdb) thread apply all bt

Thread 159 (process 1093):
#0  0x2aac15dc in _Unwind_GetCFA () from /lib/libpthread.so.0
#1  0x2afdfde8 in ?? ()
warning: GDB cant find the start of the function at 0x2afdfde8.

    GDB is unable to find the start of the function at 0x2afdfde8
and thus cant determine the size of that functions stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x2afdfde8 for code which looks like the beginning of a
function, you can increase the range of the search using the set
heuristic-fence-post command.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 158 (process 1051):
#0  0x2aac17bc in pthread_mutexattr_getprioceiling () from /lib/libpthread.so.0
#1  0x2aac17a0 in pthread_mutexattr_getprioceiling () from /lib/libpthread.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 157 (process 1057):
#0  0x2aabf908 in ?? () from /lib/libpthread.so.0
#1  0x00000000 in ?? ()

Thread 156 (process 1090):
#0  0x2aac17bc in pthread_mutexattr_getprioceiling () from /lib/libpthread.so.0
#1  0x2aac17a0 in pthread_mutexattr_getprioceiling () from /lib/libpthread.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 155 (process 1219):
#0  0x2aabf908 in ?? () from /lib/libpthread.so.0
#1  0x00000000 in ?? ()

Thread 154 (process 1218):
#0  0x2aabfb44 in connect () from /lib/libpthread.so.0
#1  0x00000000 in ?? ()

Thread 153 (process 1096):
#0  0x2abc92b4 in ?? ()
warning: GDB cant find the start of the function at 0x2abc92b4.
#1  0x2abc92b4 in ?? ()
warning: GDB cant find the start of the function at 0x2abc92b4.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 152 (process 1170):
#0  0x2aabfb44 in connect () from /lib/libpthread.so.0
#1  0x00000000 in ?? ()

Answer 1

您需要告诉gdb在哪里可以找到它的共享库。我想你是在交叉调试在另一个系统上生成的内核吧？

谷歌搜索"set solib-absolute-prefix“。

Answer 2

伙计们，非常感谢你们！

我要做的就是

设置solib绝对前缀path-to-libs

加载可执行文件和核心文件之前的 :DDDD