2010-05-28 93 views
1

我试图分析核心转储,但我得到以下结果。当main.elf动态链接时使用GDB无法分析核心转储

如果我使main.elf静态链接一切都OK,我可以看到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 ??() 

回答

7

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

Google用于“设置solib-absolute-prefix”。

+0

随着“set solib-absolute-prefix”我得到了与“set solib-search-path”相同的结果=( – dscTobi 2010-05-28 06:27:33

+0

)您正在交叉调试核心文件。核心期望在与设备相同的地方找到它的共享库核心在哪里产生。例如,如果你在设备上有/lib/libmystuff.so,你可以把它放在$ HOME/lib /中。然后你可以调用“set solib-absolute-prefix $ HOME”。 – 2010-05-28 07:25:10

2

伙计们,非常感谢你们!

所有我需要做的是

集solib绝对前缀[路径到库]

加载一个可执行文件和core文件:DDDD