我正在调查共享库的重定位，遇到了一些奇怪的事情。考虑这段代码:
int myglob;
int ml_util_func(int p)
{
return p + 2;
}
int ml_func2(int a, int b)
{
int c = ml_util_func(a);
return c + b + myglob;
}
我用 gcc -shared 将它编译成一个non-PIC 共享库。我在 x86 上运行的 32 位 Ubuntu 上执行此操作。
生成的 .so 有一个重定位条目，用于调用 ml_func2 中的 ml_util_func。这是 objdump -dR -Mintel 在 ml_func2 上的输出:
0000050d <ml_func2>:
50d: 55 push ebp
50e: 89 e5 mov ebp,esp
510: 83 ec 14 sub esp,0x14
513: 8b 45 08 mov eax,DWORD PTR [ebp+0x8]
516: 89 04 24 mov DWORD PTR [esp],eax
519: e8 fc ff ff ff call 51a <ml_func2+0xd>
51a: R_386_PC32 ml_util_func
51e: 89 45 fc mov DWORD PTR [ebp-0x4],eax
521: 8b 45 0c mov eax,DWORD PTR [ebp+0xc]
524: 8b 55 fc mov edx,DWORD PTR [ebp-0x4]
527: 01 c2 add edx,eax
529: a1 00 00 00 00 mov eax,ds:0x0
52a: R_386_32 myglob
52e: 8d 04 02 lea eax,[edx+eax*1]
531: c9 leave
532: c3 ret
533: 90 nop
注意 call 指令中的 R_386_PC32 重定位。
现在，我的问题是为什么需要搬迁？ e8 在 x86 上是“调用相对...”，并且由于 ml_util_func 是在同一对象中定义的，因此链接器肯定可以计算它与调用之间的相对偏移量而不把它留给动态加载器？
有趣的是，如果 ml_util_func 声明为 static，重定位就会消失，链接器会正确计算并插入偏移量。 ml_util_func 也被导出，这使得链接器对其懒惰是什么原因？
P.S.:我故意玩非 PIC 代码，以了解加载时重定位。
最佳答案
找不到原因，但这是 binutils 对此的评论:
binutils-2.11.90-20010705-src.tar.gz/bfd/elf32-i386.c : 679
/* If we are creating a shared library, and this is a reloc
against a global symbol, or a non PC relative reloc
against a local symbol, then we need to copy the reloc
into the shared library. However, if we are linking with
-Bsymbolic, we do not need to copy a reloc against a
global symbol which is defined in an object we are
我认为，创建此重定位是为了允许用户重载库中的任何全局符号。而且，-Bsymbolic 似乎禁用了此功能，并且不会为库本身的符号生成重定位。
http://www.rocketaware.com/man/man1/ld.1.htm
-Bsymbolic This option causes all symbolic references in the output to be resolved in this link-edit session. The only remaining run-time relocation requirements are base-relative relocations, i.e. translation with respect to the load address. Failure to resolve any symbolic reference causes an error to be reported.
各种 -B 模式和限制 (C++) 的详细描述如下:
http://developers.sun.com/sunstudio/documentation/ss12/mr/man1/CC.1.html
-Bbinding
Specifies whether a library binding for linking is
symbolic, dynamic (shared), or static (nonshared).
-Bdynamic is the default. You can use the -B
option several times on a command line.
For more information on the -Bbinding option, see
the ld(1) man page and the Solaris documentation.
-Bdynamic directs the link editor to look for
liblib.so files. Use this option if you want
shared library bindings for linking. If the
liblib.so files are not found, it looks for
liblib.a files.
-Bstatic directs the link editor to look only for
liblib.a files. The .a suffix indicates that the
file is static, that is, nonshared. Use this
option if you want nonshared library bindings for
linking.
-Bsymbolic forces symbols to be resolved within a
shared library if possible, even when a symbol is
already defined elsewhere. For an explanation of
-Bsymbolic, see the ld(1) man page.
This option and its arguments are passed to the
linker, ld. If you compile and link in separate
steps and are using the -Bbinding option, you must
include the option in the link step.
Warning:
Never use -Bsymbolic with programs containing C++
code, use linker scoping instead. See the C++
User's Guide for more information on linker scop-
ing. See also the -xldscope option.
With -Bsymbolic, references in different modules
can bind to different copies of what is supposed
to be one global object.
The exception mechanism relies on comparing
addresses. If you have two copies of something,
their addresses won't compare equal, and the
exception mechanism can fail because the exception
mechanism relies on comparing what are supposed to
be unique addresses.
关于linux - 共享库中的重定位条目，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7131360/