domain developer and not very good for other domain developers to
[Steven]: Frankly to say, the x86_64 ABI docs is only good for compiler
I am also concerned about the GOTPCRELX/REX_GOTPCRELX relocations.
Reading the x86_64 ABI docs, it appears that these may refer to
instructions that have been modified by the linker. In that case, how
do we deal with the relocation? Also, according to the doc, mov
instructions may be emitted by the linker in some cases that are only
valid in the lowest 2 GB of the address space.
My overall understanding for these different relocation type is like this:compiler generate PIC code with different "level of indirection to all global
data and function references in the code." And these different level of
indirection is implemented through GOT and PLT structure with different
addressing calculation pattern. The different calculation patterns are the
different relocation types which are defined by x86_64 ABI Table 4.9. We
don't need worry about how compiler correctly generate code to work with
these relocation types, we just need correctly understand their addressing
x86_64 ABI Table 4.9 as "G + GOT + A - P". So, I assume their difference is not
The GOTPCRELX/REX_GOTPCRELX has the same calculation definition in
in the relocation calculation pattern, but how to co-work with specific
instructions to finish these calculation in a hardware optimized way.
No, that is not what these are for. The special types mark
instructions that can be converted by the linker into simpler
sequences if the symbol turns out to be in the same module. From the
mov foo@GOTPCREL(%rip), %reg
could be converted by the linker into
lea foo(%rip), %reg
if the reference to 'foo' is satisfied by a non-preemptible local
definition. This is a useful optimization, since it eliminates a
memory load. The problem is that we cannot recalculate such
relocations in GenFw without checking whether the linker has applied
this optimization or not.
[Steven]: Do you mean the linker will apply above optimization but not remove the original GOTPCREL item? It sounds like a severe linker bug.
The fact that it works does not make it safe. Having multiple fixups
for the same symbol in the .reloc section is a problem, and so is
reapplying GOTPCRELX to places where the original instruction has been
replaced by the linker.
[Steven]: I still don't understand why there will be multiple fixups for the same symbol in the .reloc section?