首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >为什么libgcc使用全局偏移表?

为什么libgcc使用全局偏移表?
EN

Stack Overflow用户
提问于 2013-11-19 10:17:23
回答 1查看 2.3K关注 0票数 8

我正试图为i 386-精灵目标建造gcc 4.6。

我的问题如下。在编译libgcc时,我得到了利用全局偏移表的output-file _fixunsdfdi.o

该函数在将“double”转换为“unsigned”时使用。当我查看程序集时,它看起来就像放在GOT中的Wtype_MAXp1_F --但是为什么呢?

我配置了

代码语言:javascript
复制
--target=i386-elf  --enable-languages=c --disable-nls --disable-libssp --disable-libquadmath --enable-shared=no  --enable-static=yes


//Code for fixunsdfdi (from libgcc2.c)
#if defined(L_fixunsdfdi) && LIBGCC2_HAS_DF_MODE
UDWtype __fixunsdfDI (DFtype a)
{
/* Get high part of result.  The division here will just moves the radix
 point and will not cause any rounding.  Then the conversion to integral
 type chops result as desired.  */
const UWtype hi = a / Wtype_MAXp1_F;

/* Get low part of result.  Convert `hi' to floating type and scale it back,
 then subtract this from the number being converted.  This leaves the low
 part.  Convert that to integral type.  */
const UWtype lo = a - (DFtype) hi * Wtype_MAXp1_F;

/* Assemble result from the two parts.  */
return ((UDWtype) hi << W_TYPE_SIZE) | lo;
}
#endif


//Dump of the output
Class:                             32-bit
Data:                              Little Endian
Header version:                    1[Current Version]
OS/ABI:                            0[UNIX System V ABI]
Type:                              1[REL (Relocatable file)]
Machine:                           0003h[Intel Architecture EM_386]
File version:                      1[Current Version]
Entry point address:               00000000h
Start of program headers:          0 (bytes into file)
Start of section headers:          35496 (bytes into file)
Flags:                             0
Size of this header:               52 (bytes)
Size of program headers:           0 (bytes)
Number of program headers:         0
Size of section headers:           40 (bytes)
Number of section headers:         15
Section header string table index: 12

[file offset:00008AA8h]Section Headers:
[Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
[0]                    NULL            00000000 000000 000000 00     0  0   0
[1]  .text             PROGBITS        00000000 000034 000067 00 AX  0  0   4
[2]  .rel.text         REL             00000000 008E18 000018 08     13 1   4
[3]  .data             PROGBITS        00000000 00009C 000000 00 WA  0  0   4
[4]  .bss              NOBITS          00000000 00009C 000000 00 WA  0  0   4
[5]  .stab             PROGBITS        00000000 00009C 0004D4 0C     7  0   4
[6]  .rel.stab         REL             00000000 008E30 000030 08     13 5   4
[7]  .stabstr          STRTAB          00000000 000570 00844A 00     0  0   1
[8]  .rodata.cst4      PROGBITS        00000000 0089BC 000008 04 A   0  0   4
[9]  .comment          PROGBITS        00000000 0089C4 000028 01     0  0   1
[10] .eh_frame         PROGBITS        00000000 0089EC 000054 00 A   0  0   4
[11] .rel.eh_frame     REL             00000000 008E60 000008 08     13 10  4
[12] .shstrtab         STRTAB          00000000 008A40 000067 00     0  0   1
[13] .symtab           SYMTAB          00000000 008D00 0000E0 10     14 12  4
[14] .strtab           STRTAB          00000000 008DE0 000038 00     0  0   1

[file offset:00008E18h]Relocation section '.rel.text' contains 3 entries:
Type: REL
   Num:   Offset     Info    Type            Sym.Value Addend   To->Sym. Name
0:       0000000E  00000D0A R_386_GOTPC      00000000  00000003 _GLOBAL_OFFSET_TABLE_
1:       0000001A  00000709 R_386_GOTOFF     00000000  00000000 .LC0
2:       0000004A  00000809 R_386_GOTOFF     00000004  00000000 .LC1

[file offset:00008E30h]Relocation section '.rel.stab' contains 6 entries:
Type: REL
Num:   Offset     Info    Type            Sym.Value Addend   To->Sym. Name
0:       00000014  00000201 R_386_32         00000000  00000000 .text
1:       00000020  00000201 R_386_32         00000000  00000000 .text
2:       00000434  00000C01 R_386_32         00000000  00000000 __fixunsdfdi
3:       0000044C  00000201 R_386_32         00000000  00000000 .text
4:       000004C4  00000201 R_386_32         00000000  00000067 .text
5:       000004D0  00000201 R_386_32         00000000  00000067 .text

[file offset:00008E60h]Relocation section '.rel.eh_frame' contains 1 entries:
Type: REL
Num:   Offset     Info    Type            Sym.Value Addend   To->Sym. Name
0:       00000020  00000202 R_386_PC32       00000000  00000000 .text

[file offset:00008D00h]Symbol table '.symtab' contains 14 entries:
Num[h]:    Value  Size Type    Bind   Vis      Ndx Name
000000: 00000000 0000  NOTYPE  LOCAL           UND 
000001: 00000000 0000  FILE    LOCAL           ABS libgcc2.c
000002: 00000000 0000  SECTION LOCAL           1   .text
000003: 00000000 0000  SECTION LOCAL           3   .data
000004: 00000000 0000  SECTION LOCAL           4   .bss
000005: 00000000 0000  SECTION LOCAL           8   .rodata.cst4
000006: 00000000 0000  SECTION LOCAL           10  .eh_frame
000007: 00000000 0000  NOTYPE  LOCAL           8   .LC0
000008: 00000004 0000  NOTYPE  LOCAL           8   .LC1
000009: 00000000 0000  SECTION LOCAL           5   .stab
00000A: 00000000 0000  SECTION LOCAL           7   .stabstr
00000B: 00000000 0000  SECTION LOCAL           9   .comment
00000C: 00000000 0067  FUNC    GLOBAL          1   __fixunsdfdi
00000D: 00000000 0000  NOTYPE  GLOBAL          UND _GLOBAL_OFFSET_TABLE_

我不喜欢创建全局偏移表,因为我在其他地方不需要它,而且项目im中的链接器目前也不支持它。

Q1:为什么它在全局偏移表中使用符号?

Q2:是否存在避免使用全局偏移表的问题?有什么帮助吗?

EN

回答 1

Stack Overflow用户

发布于 2014-05-22 18:13:39

好吧,我不确定我是否完全理解了,但现在.

Q1:为什么它在全局偏移表(GOT)中使用符号?

之所以使用GOT,是因为编译器、链接器和加载程序的工作方式是不可能知道每个对象在运行时将在哪个内存中结束。编译器正确的步骤一次只看到一个模块,因此它无法从引用每个(外部)函数和全局var的位置来判断。相反,它为每个符号创建一个符号,以便在链接时解析。对于静态函数/变量,它生成直接访问这些函数/变量的代码(它依赖于平台:在Linux/x86_64中使用来自程序计数器的偏移量)。对于外部环境,它通过运行时数据结构生成间接访问代码: GOT。

在链接时,您可以知道哪些模块调用什么符号,因此确保所有符号(程序中的符号或其外部依赖项中的符号)都已被解析,这意味着它们是在组成程序的多个模块的其他地方定义的。对于在您自己的代码(或静态链接)中定义的对象,可以告诉它在二进制文件中的位置(ELF/COFF/PE/等等),但是直到加载时才知道它们在内存中的位置。链接器还在二进制文件中写入所需的共享库以及(可选)它们在运行时的可能位置。

当你运行你的程序时,装载机!将尝试查找所有依赖项(共享库),然后作为进程启动的一部分将构建GOT结构。它将把程序代码从二进制文本部分加载到内存中,并为每个符号创建一个带有实际内存地址的GOT条目。然后,它将对每个共享库执行相同的操作。还值得注意的是,一些库可能会保持内部偏移表独立于GOT。这样,您就可以多次定义相同的符号。这就是窗口SxS发生的例子!(微软对DLL地狱问题的回答)。

从程序的角度来看,每次访问外部符号都需要两个内存访问(间接)。如果符号表示一个函数,则有另一个结构PLT,即一个跳转表,其中每个位置都有GOTO指令。

Q2:是否存在避免使用全局偏移表的问题?有什么帮助吗?

是的,最简单的方法是找出您不需要在模块外部访问的函数/全局,并将它们声明为静态的。通过这种方式,编译器将知道它可以生成直接访问代码来查找它们(在Linux/x86_64中,与程序计数器的偏移是这样做的,但它是与平台相关的)。

我曾经读过,在大型项目中,有一个专门的构建团队来识别紧密耦合的模块集,并将它们集成到一个大C文件中,以便将公开符号的数量最小化到通用产品中,但我从未亲眼看到过它。

还有一些链接选项可以帮助您避免暴露符号,但我知道它们只是语法糖。GOT和PLT还在使用,只是你让它的内容不透明。

这个主题的一个很好的资源是Ulrich的如何编写共享库

票数 4
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/20068781

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档