2010-05-28 90 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