Linux 这个警告是什么意思?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/4182447/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-04 23:58:25  来源:igfitidea点击:

What does this warning mean?

linuxdynamicgdbwarnings

提问by 341008

I have often encountered the following warning from gdb:

我经常遇到来自 gdb 的以下警告:

warning: .dynamic section for XXX is not at the expected address

warning: .dynamic section for XXX is not at the expected address

where XXX is the name of some library. Most recently I got it for libgobject-2.0.so. My app uses GTK. gdb had been launching it without problems till yesterday when I synced the latest code from the repository and built it afresh. Since then it has been complaining about .dynamic section. What are the possible reasons for it? And how do I resolve them?

其中 XXX 是某个库的名称。最近我为 libgobject-2.0.so 获得了它。我的应用程序使用 GTK。直到昨天,当我从存储库同步最新代码并重新构建它时,gdb 一直没有问题地启动它。从那以后,它一直在抱怨 .dynamic 部分。可能的原因是什么?我该如何解决它们?

采纳答案by thkala

Some gdb versions are actually a bit more helpful with that warning. They output something like the following:

一些 gdb 版本实际上对这个警告更有帮助。他们输出如下内容:

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

警告:“libhello.so”的 .dynamic 部分不在预期地址(错误的库或版本不匹配?)

Make sure GDB finds the library your program was actually compiled with and that any debugging symbols, if in separate files, for the application and the library are current and consistent with the builds you are using.

确保 GDB 找到您的程序实际编译时使用的库,并且应用程序和库的任何调试符号(如果在单独的文件中)都是最新的并且与您正在使用的构建一致。

An upgrade sounds like a good suspect for a cause. Prelinking libraries might also cause this warning to appear, although I think gdb can handle that case.

升级听起来像是一个很好的原因。预链接库也可能导致出现此警告,尽管我认为 gdb 可以处理这种情况。

回答by Carlo Wood

I ran into this problem too just now and it can't be caused by what thkala mentioned... Live investigation follows.

我刚才也遇到了这个问题,它不可能是由 thkala 提到的引起的……下面是实时调查。

I have a single gdb running. ps fax | grep -B1 Hymandbusshows:

我有一个 gdb 正在运行。ps fax | grep -B1 Hymandbus显示:

61747 pts/8    Sl+    0:00  |       \_ gdb
61764 pts/8    t      0:00  |           \_ /usr/src/Hyman2/pkg/Hyman2/usr/bin/Hymandbus auto

Inside that gdb I had a breakpoint on main(so it never really ran), but I did run it (with arg auto) to load the shared libraries, and gdb prints:

在那个 gdb 里面我有一个断点main(所以它从来没有真正运行过),但我确实运行了它(使用 arg auto)来加载共享库,并且 gdb 打印:

warning: .dynamic section for "/usr/src/Hyman2/pkg/Hyman2/usr/lib/libHymanserver.so.0" is not at the expected address (wrong library or version mismatch?)

Unless there is something extremely wrong with the build system of Hyman2, those two belong together (were compiled at the same time).

除非 Hyman2 的构建系统出了什么问题,否则这两者是属于一起的(同时编译的)。

So what is causing this warning? My investigation:

那么是什么导致了这个警告呢?我的调查:

# cat /proc/61764/maps | grep 'Hyman'
555555554000-55555555a000 r--p 00000000 00:2f 33145                      /usr/src/Hyman2/pkg/Hyman2/usr/bin/Hymandbus
55555555a000-555555566000 r-xp 00006000 00:2f 33145                      /usr/src/Hyman2/pkg/Hyman2/usr/bin/Hymandbus
555555566000-55555556d000 r--p 00012000 00:2f 33145                      /usr/src/Hyman2/pkg/Hyman2/usr/bin/Hymandbus
55555556e000-555555570000 r--p 00019000 00:2f 33145                      /usr/src/Hyman2/pkg/Hyman2/usr/bin/Hymandbus
555555570000-555555571000 rw-p 0001b000 00:2f 33145                      /usr/src/Hyman2/pkg/Hyman2/usr/bin/Hymandbus
7ffff7efe000-7ffff7f29000 r--p 00000000 fe:03 1976021                    /usr/lib/libHymanserver.so.0.1.0
7ffff7f29000-7ffff7f72000 r-xp 0002b000 fe:03 1976021                    /usr/lib/libHymanserver.so.0.1.0
7ffff7f72000-7ffff7f99000 r--p 00074000 fe:03 1976021                    /usr/lib/libHymanserver.so.0.1.0
7ffff7f99000-7ffff7f9a000 ---p 0009b000 fe:03 1976021                    /usr/lib/libHymanserver.so.0.1.0
7ffff7f9a000-7ffff7fa0000 r--p 0009b000 fe:03 1976021                    /usr/lib/libHymanserver.so.0.1.0
7ffff7fa0000-7ffff7fa1000 rw-p 000a1000 fe:03 1976021                    /usr/lib/libHymanserver.so.0.1.0

Hit in one... The actualshared library that is loaded is /usr/lib/libHymanserver.so.0.1.0.

一击中...加载的实际共享库是/usr/lib/libHymanserver.so.0.1.0.

gdb is simply lying about the path what was actually loaded (and its still a case of what thkala mentioned)!

gdb 只是在实际加载的路径上撒谎(它仍然是 thkala 提到的情况)!

Also note the output of info shared:

还要注意输出info shared

From                To                  Syms Read   Shared Object Library
0x00007ffff7f29040  0x00007ffff7f71ed3  Yes         /usr/src/Hyman2/pkg/Hyman2/usr/lib/libHymanserver.so.0

The library at that path doeshave debug info (but the missing (*)below Read) means that Shared library is missing debugging information.Another indication that the actual library loaded and the path shown here are not the same.

该路径的库确实有调试信息(但(*)下面缺少Read)意味着Shared library is missing debugging information.加载的实际库与此处显示的路径不同的另一个指示。

Note that I have the following gdb variables set:

请注意,我设置了以下 gdb 变量:

(gdb) show sysroot
The current system root is "/nonexistent".
(gdb) show solib-search-path
The search path for loading non-absolute shared library symbol files is /usr/src/Hyman2/pkg/Hyman2/usr/lib:/usr/lib.

(See set solib-search-pathon the page https://sourceware.org/gdb/current/onlinedocs/gdb/Files.html#index-shared-librariesfor the reason why).

(请参阅set solib-search-path页面https://sourceware.org/gdb/current/onlinedocs/gdb/Files.html#index-shared-libraries了解原因)。

Apparently, setting solib-search-pathhas an effect on where gdb finds the shared libraries, but NOT on which shared libraries are actually loaded.

显然,设置solib-search-path会影响 gdb 找到共享库的位置,但不会影响实际加载的共享库。

Following thisanswer I therefore added also set environment LD_LIBRARY_PATH=/usr/src/Hyman2/pkg/Hyman2/usr/libto /usr/src/Hyman2/.gdbinit(from where I am running gdb; note that I have in my ~/.gdbinitthe line: add-auto-load-safe-path /usr/src/Hyman2in order to actually load it). It turned out that I could also simply delete the lines that set sysroot and solib-search-path. The complete .gdbinitnow being:

因此,在这个答案之后,我还添加set environment LD_LIBRARY_PATH=/usr/src/Hyman2/pkg/Hyman2/usr/lib/usr/src/Hyman2/.gdbinit(从我运行的地方gdb;请注意,我在我~/.gdbinit的行中:add-auto-load-safe-path /usr/src/Hyman2为了实际加载它)。事实证明,我也可以简单地删除设置 sysroot 和 solib-search-path 的行。完整的.gdbinit现在是:

cd /usr/src/Hyman2
directory src/Hyman2-1.9.14/linux
set environment LD_LIBRARY_PATH=/usr/src/Hyman2/pkg/Hyman2/usr/lib
file pkg/Hyman2/usr/bin/Hymandbus
set args auto
b main
command 1
b HymanLinuxFutex.cpp:137
b HymanLinuxFutex.cpp:156
end
run

This solved the problem.

这解决了问题。