Linux 过程联动表和全局偏移表

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/9688076/
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-06 05:08:49  来源:igfitidea点击:

Process Linkage Table and Global Offset Table

clinuxgccx86-64

提问by MetallicPriest

I am reading this article on PLT (Process Linkage Table) and GOT (Global Offset Table). While the purpose of PLT is clear to me, I'm still confused about GOT. What I've understood from the article is that GOT is only necessary for variables declared as externin a shared library. For global variables declared as staticin a shared library code, it is not required.

我正在阅读有关 PLT(过程链接表)和 GOT(全局偏移表)的这篇文章。虽然 PLT 的目的对我来说很清楚,但我仍然对 GOT 感到困惑。我从文章中了解到,只有extern在共享库中声明的变量才需要 GOT 。对于static在共享库代码中声明的全局变量,它不是必需的。

Is my understanding right, or am I completely missing the point.

我的理解是对的,还是我完全没有抓住重点。

回答by R.. GitHub STOP HELPING ICE

Perhaps your confusion is with the meaning of extern. Since the default linkage is extern, any variable declared outside function scope without the statickeyword is extern.

也许您的困惑与 的含义有关extern。由于默认链接为extern,因此在函数作用域之外声明的任何变量都没有static关键字 is extern

The reason the GOT is necessary is because the address of variables accessed by the shared library code is not known at the time the shared library is generated. It depends either on the load address the library gets loaded at (if the definition is in the library itself) or the third-party code the variable is defined in (if the definition is elsewhere). So rather than putting the address inline in the code, the compiler generates code to read the shared library's GOT and then loads the address from the GOT at runtime.

之所以需要GOT,是因为在生成共享库时,共享库代码访问的变量地址是未知的。它取决于加载库的加载地址(如果定义在库本身中)或定义变量的第三方代码(如果定义在别处)。因此,编译器生成代码读取共享库的 GOT,然后在运行时从 GOT 加载地址,而不是将地址内联到代码中。

If the variable is knownto be defined within the same shared library (either because it's staticor the hiddenor protectedvisibility attribute it used) then the address relative to the code in the librarycan be fixed at the time the shared library file is generated. In this case, rather than performing a lookup through the GOT, the compiler just generates code to access the variable with program-counter-relative addressing. This is less expensive both at runtime and at load time (because the whole symbol lookup and relocation process can be skipped at load time).

如果该变量是已知要在相同的共享库中定义(或者因为它是statichiddenprotectedvisibility属性它使用),则地址相对于所述代码库中的可被固定在生成的共享库文件的时间。在这种情况下,编译器不会通过 GOT 执行查找,而是生成代码来访问具有程序计数器相对寻址的变量。这在运行时和加载时都比较便宜(因为可以在加载时跳过整个符号查找和重定位过程)。