Re: [PATCH v2 2/7] BaseTools-GenFw:Add new x86_64 Elf relocation types for PIC/PIE code

["Shi, Steven" <steven.shi@intel.com>]

> >>
> >> 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.
> >>
> > [Steven]: Frankly to say, the x86_64 ABI docs is only good for compiler
> domain developer and not very good for other domain developers to
> understand it.
> > 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
> calculation pattern.
> >
> > The GOTPCRELX/REX_GOTPCRELX has the same calculation definition in
> x86_64 ABI Table 4.9 as "G + GOT + A - P". So, I assume their difference is not
> 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
> doc:
> 
> 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?