[RFC] Clarify x86-64 GOT slot access

[H.J. Lu]

x86-64 GOT is

extern Elf64_Addr _GLOBAL_OFFSET_TABLE_ [];

Each slot contains the symbol run-time address. For memory access of
GOT relocations, like "foo@GOTPCREL(%rip)", memory beyond its GOT
slot is undefined, which can be anything, including unmapped or unreadable
memory. Should psABI clarify that memory access of GOT relocations beyond
its GOT slot is unsupported?

--
H.J.

[Michael Matz]

Hello,

On Sat, 15 Feb 2025, H.J. Lu wrote:

> x86-64 GOT is
>
> extern Elf64_Addr _GLOBAL_OFFSET_TABLE_ [];

That is more or less used as an informal description for the concept for
readers accustomed to C. What the GOT _really_ is is an arbitrary blob of
memory where some places are indexed by numbers and offsets, and where
some of these very places are initialized via runtime relocations, or via
putting seemingly arbitrary numbers into the contents (which then
usually happen to be fully resolved addresses generated during link
editing).

The GOT need not even be contiguous, it need not consist of only GOT
slots, and there is no inherent relation between different GOT slots. The
symbol _GLOBAL_OFFSET_TABLE_ need not point into the GOT, as long as all
GOT slots can be addressed via signed 32bit offsets from it. In fact it
may not exist at all, when unreferenced.

All these things do happen to be the case in practice with current
toolchains but are merely conventions or implementation details without
technical necessity.

"The" GOT also doesn't exist in the memory view. All GOT slots will
be part of some loadable segment, that's about it. (certain dynamic
entries will point into those segments at points that relate to what was
"the" GOT, these are optional)

> Each slot contains the symbol run-time address. For memory access of
> GOT relocations, like "foo@GOTPCREL(%rip)", memory beyond its GOT slot
> is undefined, which can be anything, including unmapped or unreadable
> memory. Should psABI clarify that memory access of GOT relocations
> beyond its GOT slot is unsupported?

I don't think so. There is no requirement for putting in such
restriction. E.g. as far as the psABI is concerned it's fine if some
tightly coupled toolchain would (say) make all GOT slots be 16 bytes and
aligned to that, and use 16byte loads to access them. Stupid, but such
object wouldn't be, and shouldn't be, non-compliant with the psABI.

Of course it would remain invalid to access any data item beyond its
section limit. That is the case always, for all items, it's not
restricted to GOT slots and it would be odd to specifically call out the
GOT items.

The psABI already describes how GOT slots generated in response to
certain relocations are at least allocated, so it gives some minimum
guarantees of what is possible to do with such slots. The psABI is not
the place to set arbitrary additional restrictions: if a toolchain chooses
to guarantee more, then more power to them. They shouldn't be in
violation of the psABI.


Ciao,
Michael.