gdb的警告

alaulong

This GDB was configured as "i386-redhat-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) r
Starting program: /home/godlongv/code/cwork/c/hou

warning: Missing the separate debug info file: /usr/lib/debug/.build-id/ac/2eeb206486bb7315d6ac4cd64de0cb50838ff6.debug

warning: Missing the separate debug info file: /usr/lib/debug/.build-id/ba/4ea1118691c826426e9410cafb798f25cefad5.debug
0

Program exited with code 02.
有上邊的兩警告，沒法調(diào)試怎么回事？

cugb_cat

編譯的時(shí)候沒加-g選項(xiàng)？

prolj

原帖由 cugb_cat 于 2007-12-31 20:36 發(fā)表
編譯的時(shí)候沒加-g選項(xiàng)？

告訴人家，－g 是帶調(diào)試符號的

alaulong

我發(fā)誓，一定加了"-g"了。

雨絲風(fēng)片

你的調(diào)試信息被分離在了單獨(dú)的文件中，調(diào)試時(shí)，gdb通過符號表文件里的鏈接又找不到單獨(dú)
存放調(diào)試信息的那個文件。請確認(rèn)一下你的調(diào)試環(huán)境和編譯環(huán)境是否一致？根據(jù)錯誤信息查看
指定目錄和指定文件是否存在并確認(rèn)錯誤原因。如果文件存在，再通過設(shè)置gdb的調(diào)試信息文件
目錄來讓gdb找到它。

albcamus

原帖由 雨絲風(fēng)片 于 2008-1-1 13:50 發(fā)表
你的調(diào)試信息被分離在了單獨(dú)的文件中，調(diào)試時(shí)，gdb通過符號表文件里的鏈接又找不到單獨(dú)
存放調(diào)試信息的那個文件。請確認(rèn)一下你的調(diào)試環(huán)境和編譯環(huán)境是否一致？根據(jù)錯誤信息查看
指定目錄和指定文件是否存在并確認(rèn)錯誤原因。如果文件存在，再通過設(shè)置gdb的調(diào)試信息文件
目錄來讓gdb找到它。

通過google搜索到了這里。

問題和樓主一模一樣。 編譯環(huán)境和調(diào)試環(huán)境完全一樣， 它指定的那個文件壓根不存在。

我的程序：

#include <stdio.h> const char array[] = "\x6b\xc0\xe8\x2e\x7e\xf6\xff\xe8\xd1\x16\xf2\xff\xb8\x01\x00\x00\x00\xe8\xaa\x1c\xf4\xff\x89\xd8\x83\xc4\x10\x5b\x5d\xc3\x90\x90\x90\x55\x89\xe5\x53\x83\xec\x0c\x8b\x48\x04\x8b\x11\x39\xc2\x74\x18\x89\x54\x24\x08\x89\x44\x24\x04\xc7\x04\x24\xbe\x32\x6b\xc0"; int main(int argc, char *argv[]) {     printf("%p\n", array);     *(int *)0 = 0;     return 0; }

大家可以自己試試有沒有這個問題。 我是在gdb中run時(shí)出現(xiàn)的警告。

Fixend

原帖由 albcamus 于 2008-1-10 17:21 發(fā)表


通過google搜索到了這里。

問題和樓主一模一樣。 編譯環(huán)境和調(diào)試環(huán)境完全一樣， 它指定的那個文件壓根不存在。

我的程序：

#include

const char array[] = "\x6b\xc0\xe8\x2e\x7e\xf6\xff\xe ...

我這里沒有問題，似乎是gdb的問題。

1. fixend% gdb -v
   
2. GNU gdb 6.6-debian
   
3. Copyright (C) 2006 Free Software Foundation, Inc.
   
4. GDB is free software, covered by the GNU General Public License, and you are
   
5. welcome to change it and/or distribute copies of it under certain conditions.
   
6. Type "show copying" to see the conditions.
   
7. There is absolutely no warranty for GDB.  Type "show warranty" for details.
   
8. This GDB was configured as "i486-linux-gnu".
   

復(fù)制代碼

1. 
   
2. fixend% uname -a
   
3. Linux ubuntu 2.6.22-14-F #12 Wed Jan 9 20:19:22 CST 2008 i686 GNU/Linux
   

復(fù)制代碼

雨絲風(fēng)片

應(yīng)該是具體環(huán)境的問題，從現(xiàn)象上來看，是調(diào)試環(huán)境中的庫采用了分離調(diào)試信息文件的方式，而又沒有另外安裝調(diào)試信息文件。
網(wǎng)上搜到下面內(nèi)容，給出了一些解決辦法的郵件鏈接，可以參考一下。

GDB Messages Enhanced To Indicate Missing Debuginfo Files

A query from NealBecker asked[1] why running gdb on a program now produced many warnings of the form "Missing the separate debug info file: /usr/lib/debug/.build-id/XXXXXXX.debug". AndrewHaley responded[2] that the problem was that the appropriate "-debug" packages for the shared libraries were not installed and suggested that the absence of specific information as to which libraries were missing was a bug.

[1] https://www.redhat.com/archives/ ... nuary/msg00300.html

[2] https://www.redhat.com/archives/ ... nuary/msg00302.html

While acknowledging that it was slightly awkward to find the information MattMiller suggested[3] enabling the debuginfo repository so that YUM could be used to install the missing filename's package. JesseKeating added[4] that it was easier to use debuginfo-install <appname> which would automatically enable the debuginfo repository and install the requisite debuginfo packages. A very informative post from JanKratochvil, a Red Hat employee primarily focusing on GDB, followed[5]. Jan's post showed how to find the name of the library missing debuginfo ls -l /usr/lib/debug/.build-id/fa/XXXX.debug, how to find the RPM package name to install the debuginfo repoquery -qf /usr/lib/debug/.build-id/fa/XXXXX.debug and as suggested previously by MattMiller how to simply install the missing debuginfo package with yum install /usr/lib/debug/.build-id/fa/XXXXX.debug. Jan cautioned that debuginfo-install <appname> method might not work due to multiple simultaneous debuginfo versions present and he also encouraged discussion on how to improve the output.

[3] https://www.redhat.com/archives/ ... nuary/msg00306.html

[4] https://www.redhat.com/archives/ ... nuary/msg00307.html

[5] https://www.redhat.com/archives/ ... nuary/msg00308.html

Further discussion between AndrewHaley and Jan on how to improve the ability of GDB to suggest the correct debuginfo packages uncovered some constraints. Jan pointed[6] out that debuginfo-install will have problems with dynamically opened libraries, that printing out a suggested RPM package would unacceptably tie GDB to Fedora. These debuginfo files are the result of work by RolandMcGrath and others on BuildID, which is a Fedora 8 feature[7][8], which extended the information in core files to include specific versions of binaries and dynamic shared objects. This enables precise replication of a problem for debugging. Implementing this required changes to the kernel[8a], ld and other parts of the compiler toolchain and so are of general interest, non-exclusive to Fedora. AndrewHaley suggested[9] that a local (to Fedora) patch could produce his version of perfection, which would be to suggest a specific yum installation command. JamesAntill thought[10] that if perfection and local patching were being considered then tighter integration with rpm or yum could allow the use of debuginfo-install <packagename>.

[6] https://www.redhat.com/archives/ ... nuary/msg00312.html

[7] http://fedoraproject.org/wiki/Releases/FeatureBuildId

[8] Section 15.2 of the gdb info file explains that a build-id is a section of the executable file which is a unique identification hash which remains constant across multiple builds of the same build tree.

[8a] http://www.uwsg.indiana.edu/hype ... el/0707.1/1702.html

[9] https://www.redhat.com/archives/ ... nuary/msg00317.html

[10] https://www.redhat.com/archives/ ... nuary/msg00339.html

When TomLondon experimented[11] with debuginfo-install and got a large list of dependencies Jan asked[12] why debuginfo packages were pulling in binary packages and suggested a patch to the redhat rpm macros. RolandMcGrath responded[13] with a suggestion that redhat-rpm-config should also change.

[11] https://www.redhat.com/archives/ ... nuary/msg00350.html

[12] https://www.redhat.com/archives/ ... nuary/msg00353.html

[13] https://www.redhat.com/archives/ ... nuary/msg00362.html

In closing DavidNielsen suggested[14] that PackageKit might aid in figuring out which packages were missing and offering to install them for the user.

[14] https://www.redhat.com/archives/ ... nuary/msg00355.html

honeyheng

不知道LZ這個問題解決了沒有？我遇到了和你完全相同的問題，到底該怎么處理呢？我是新手，麻煩各位幫忙。