问题描述
我得到下面的错误,当我尝试调试核心文件。如何解决这个问题。
就在几天前,它正在罚款。
我尝试运行/ sbin目录/ ldconfig的与根provileges。 code编译时:
G ++ -fPIC -ggdb
我的可执行文件是32位二进制:
$文件申请ELF 32位LSB的可执行文件,ARM版本1(SYSV),动态链接
(使用共享库),不剥离。
用户@ UBU:到/ mnt / HGFS /股$ GDB申请core.11_416
GNU GDB(Ubuntu的/ Linaro的7.4-2012.04-0ubuntu2.1)7.4-2012.04
版权所有(C)2012自由软件基金会
许可GPLv3的+:GNU GPL第3版或更高版本< HTTP://gnu.org/licenses/gpl.html>
这是自由软件:您可以自由修改和重新发布。
没有担保,在法律允许的范围内。键入显示复制
和显示保修的说明。
这是GDB配置为i686的Linux的GNU的。
对于错误报告的说明,请参阅:
< HTTP://bugs.launchpad.net/gdb-linaro/> ...
阅读从/mnt/hgfs/share/appl...done符号。警告:找不到核心文件的通用寄存器。警告:无法加载共享库符号9文库,例如/lib/libdl.so.2。
使用info sharedlibrary命令来查看完整列表。
你需要设置solib搜索路径或设置SYSROOT?
核心是由'申请'产生。
警告:找不到核心文件的通用寄存器。
#0℃;不可>在?? ()
(GDB)我共享
从到西姆斯读取共享对象库
没有/lib/libdl.so.2
没有/opt/lib/libappl.so
没有/lib/librt.so.1
没有/usr/lib/libstdc++.so.6
没有/lib/libm.so.6
没有/lib/libgcc_s.so.1
没有/lib/libc.so.6
没有/lib/libpthread.so.0
没有/lib/ld-linux.so.3
(GDB)
(GDB)显示solib搜索路径
加载非绝对共享库符号文件的搜索路径。
(GDB)显示SYSROOT
目前的系统根目录为。
(GDB)
(GDB)秀阿尔基
目标架构是自动设置(目前为386)
我使用VMware运行Ubuntu 12.04
用户@ UBU:〜$的uname -a
Linux的UBU 3.2.0-36泛型#57,Ubuntu的SMP星期二1月8日二十一点41分24秒UTC 2013 i686的的i686 i386的GNU / Linux的
用户@ UBU:〜$
修改:20-MAR-2013
@SCOTT:感谢您的答复。我会尝试了这一点。相同的设置是罚款早期工作,我能够用GDB调试。一旦我做了apt-get的更新,从那时起GDB抱怨上述错误。一个区别,我可以做出来是年初的时候GDB是工作优化版本是显示:
这是GDB配置为i486的Linux的GNU的。
现在更新后的版本显示:
这是GDB配置为i686的Linux的GNU的
这是我所看到或理解所有的差异。
这是我使用不具备GDB提供了ARM工具链。在G ++编译为英特尔。我使用同样的G ++生成可执行现在也。
$文件G ++
G ++:ELF 32位LSB的可执行文件,英特尔80386,版本1(SYSV),动态链接(使用共享库),为GNU / Linux 2.2.5,剥去
这是我使用所提供的交叉编译器可执行如下所示。但是,当我得到这个错误我用的是普通的gdb(安装在Ubuntu)命令只能是在在/ usr /斌/广发行
用户@ UBU中:/ opt / CS /斌$ LS
臂无-Linux的gnueabi-G ++
臂无-Linux的gnueabi-GDB...等...
我在这里用错了GDB。如果这是错误的GDB,为什么它的工作较早,现在为什么不呢?如果我用这个胳膊没有-Linux的gnueabi-GDB调试ARM交叉编译的应用程序,这是与编译:
ARM-NONE-Linux的gnueabi-G ++ appl.cpp -o申请
用户@ UBU:〜$其中GDB
在/ usr /斌/ GDB
您使用了错误的gdb。抓住 Linaro的工具链ARM tar包,解压并运行:
$ GCC-Linaro的臂-Linux的gnueabihf-4.7-2013.02-01-20130221_linux /斌/ ARM-Linux的gnueabihf-GDB申请core.11_416
< ...>
这是GDB配置为主机= i686的-build_pc-Linux的GNU --target =臂Linux的gnueabihf。
< ...>
请注意你使用显示了GDB这是GDB配置为的i686-Linux的GNU 。你想一个显示的 - 主机= i686的-build_pc-Linux的GNU --target =臂Linux的gnueabihf(或类似的ARM Linux的三靶)
。通常人们不会混淆了一个gcc打靶的 ARM-Linux的gnueabihf 用gdb的目标定位的i686-Linux的GNU 因为编译器,连接器和调试器命令会都开始用相同的preFIX,即 ARM-Linux的gnueabihf- {GCC,GDB,LD,气} 等,你是怎么结束与特定的gcc和gdb组合?
i get the below error when i try to debug the core file. How to solve this issue.Just some days ago it was working fine.I tried running "/sbin/ldconfig" with root provileges. Code is compiled with :
g++ -fPIC -ggdb
My executable is 32-bit binary:
$ file appl
ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked
(uses shared libs), not stripped.
user@ubu:/mnt/hgfs/share$ gdb appl core.11_416
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /mnt/hgfs/share/appl...done.
warning: Couldn't find general-purpose registers in core file.
warning: Could not load shared library symbols for 9 libraries, e.g. /lib/libdl.so.2.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `appl'.
warning: Couldn't find general-purpose registers in core file.
#0 <unavailable> in ?? ()
(gdb) i shared
From To Syms Read Shared Object Library
No /lib/libdl.so.2
No /opt/lib/libappl.so
No /lib/librt.so.1
No /usr/lib/libstdc++.so.6
No /lib/libm.so.6
No /lib/libgcc_s.so.1
No /lib/libc.so.6
No /lib/libpthread.so.0
No /lib/ld-linux.so.3
(gdb)
(gdb) show solib-search-path
The search path for loading non-absolute shared library symbol files is .
(gdb) show sysroot
The current system root is "".
(gdb)
(gdb) show archi
The target architecture is set automatically (currently i386)
I am using VMware running ubuntu 12.04
user@ubu:~$ uname -a
Linux ubu 3.2.0-36-generic #57-Ubuntu SMP Tue Jan 8 21:41:24 UTC 2013 i686 i686 i386 GNU/Linux
user@ubu:~$
EDIT : 20-Mar-2013
@SCOTT: Thanks for reply. I will try this out. The same setup was working fine earlier and i was able to debug with GDB. Once i did a "apt-get update", and since then GDB is complaining the above errors. One difference which i can make out was earlier when GDB was working the verion was showing:
This GDB was configured as "i486-linux-gnu".
Now the the version after update shows:
This GDB was configured as "i686-linux-gnu"
That's all the difference which i can see or understand.
The ARM tool chain which i use doesn't have the GDB provided with. The g++ is compiled for Intel. I use this same g++ to build the executable now also.
$ file g++
g++: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped
The provided cross-compiler executable which i use are as below. But when i got this error I was using the normal gdb (installed on Ubuntu) command only which is at "/usr/bin/gdb":
user@ubu:/opt/cs/bin$ ls
arm-none-linux-gnueabi-g++
arm-none-linux-gnueabi-gdb
... etc ...
Am i using wrong GDB here. If it was wrong GDB, why it was working earlier now why not? Should i use this arm-none-linux-gnueabi-GDB to debug the ARM cross compiled application, which is compiled with:
arm-none-linux-gnueabi-g++ appl.cpp -o appl
user@ubu:~$ which gdb
/usr/bin/gdb
You're using the wrong gdb. Grab the Linaro ARM toolchain tarball, extract it and run:
$ gcc-linaro-arm-linux-gnueabihf-4.7-2013.02-01-20130221_linux/bin/arm-linux-gnueabihf-gdb appl core.11_416
<...>
This GDB was configured as "--host=i686-build_pc-linux-gnu --target=arm-linux-gnueabihf".
<...>
Note the gdb you're using shows "This GDB was configured as "i686-linux-gnu"". You want one that shows "--host=i686-build_pc-linux-gnu --target=arm-linux-gnueabihf" (or similar ARM Linux triplet in target).
Usually people wouldn't mix up a gcc targetting arm-linux-gnueabihf with a gdb targetting i686-linux-gnu because the compiler, linker and debugger commands would all start with the same prefix, i.e. arm-linux-gnueabihf-{gcc,gdb,ld,gas} etc. How did you end up with your particular gcc and gdb combination?
这篇关于找不到核心文件的通用寄存器的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!