google key: gdb問號

我的程式crash,有了coredump檔案，在Linux PC上用arm-linux-gdb debug it. The result is:

#0  0x4022b178 in ?? ()
(gdb) bt
#0  0x4022b178 in ?? ()
#1  0x4022b134 in ?? ()
#2  0x4022b134 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
why? I can't locate the correct location, find the really reason.

看看載入的內容

GNU gdb 6.6
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=i686-pc-linux-gnu --target=arm-linux"...

warning: core file may not match specified executable file.

warning: .dynamic section for "/lib/libdl.so.2" is not at the expected address (wrong library or version mismatch?)

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/libstdc++.so.6: No such file or directory.

warning: .dynamic section for "/lib/libm.so.6" is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for "/lib/libgcc_s.so.1" is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for "/lib/libc.so.6" is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for "/lib/ld-linux.so.2" is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for "/lib/libnss_files.so.2" is not at the expected address (wrong library or version mismatch?)
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Symbol file not found for /lib/libstdc++.so.6
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Core was generated by `./6800plusEth.bin'.
Program terminated with signal 11, Segmentation fault.

一些庫找不到(/lib/libstdc++.so.6)，或者版本不匹配。我不應該載入/lib/libdl..so.... 這些檔案，這是針對X86的。

所以兩個命令至關重要:

set solib-absolute-prefix -- Set prefix for loading absolute shared library symbol files
set solib-search-path -- Set the search path for loading non-absolute shared library symbol files

比如：set solib-... /usr/local/arm-linux/arm-linux/lib/, 兩個引數的值一樣就可以了。

先啟動arm-linux-gdb,設定變數以後，via core-file load core dump file to analyze it.

#gdb

#set solib-absolute-prefix "library path"

#set solib-search-path "library path"

#file file.debug

#core-file core.1234

但是還是不能準確定位，查詢embedded linux版本：

uname -a

ls -l /usr/arm-linux/gcc-3.4.1-glibc-2.3.3/arm-linux/lib/libc-2.3.3.so

Linux PC上的呢：

ll /usr/local/arm/3.4.1/arm-linux/lib/libc-2.3.2.so

原來庫檔案不對，一個是2.3.3，另一個是2.3.2，此時發現版本匹配是至關的重要啊！！

換了一個Linux PC，它的交叉編譯環境是2.3.3

哈哈！立即定位到了錯誤的原因！！

///

一.關於gdb除錯core檔案總是一堆問號的問題
問題描述：已經在編譯選項中加入了-g，但是檢視core檔案時，還是一堆問號，使用的命令為:gdb -c core
解決方案：由於gdb -c core這樣的使用在有些系統下支援不是很好，所以推薦用如下兩種方法：

1）gdb exe
(gdb) core-file core

2）gdb -c core
(gdb) file exe

而其中第二種方法在某些系統上也是不好用的，所以就用第一種即可。