3

The whole reason the GOT works is that the offset between the code and data sections is constant; ergo, the offset between the code and some given datum in the data section is constant.

This SO question addresses this, and confirms that for data defined in the library, the GOT is redundant.

The only possibility left is data used in the library, but defined elsewhere.

Thus, is the only point of the GOT in a shared lib, to be able to keep that lib's code section position-independent by localizing all relocations to symbols defined in other shared libraries, in the GOT?

Community
  • 1
  • 1
Kat
  • 473
  • 5
  • 17
  • You're overlooking symbol interposition: https://www.macieira.org/blog/2012/01/sorry-state-of-dynamic-libraries-on-linux/. That makes access to your own global vars and functions inefficient in a shared library unless you set their ELF visibility to `hidden`. – Peter Cordes Apr 09 '19 at 08:17

1 Answers1

0

Thus, is the only point of the GOT in a shared lib, to be able to keep that lib's code section position-independent by localizing all relocations to symbols defined in other shared libraries, in the GOT?

You are correct that the GOT is the mechanism which allows code to be relocatable.

However, it applies to both traditional shared objects and programs. It applies to programs due to Position Independent Code (PIE) (a.k.a Address Space Layout Randomization).

Generally speaking, PIE is a subset of PIC. That is, you can compile all code (programs and shared libraries) with -fPIC. However, the converse is not true. You cannot compile all code (programs and shared libraries) with -fPIE. Shared libraries require -fPIC.

jww
  • 97,681
  • 90
  • 411
  • 885