GDB 调试遇到??的问题

今天总算解决了一个大的bug,爽！

个人程序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

而其中第二种方法在某些系统上也是很差用的，因此就用第一种便可。