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

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

> >
> > That was not my point. With your code, how many
> > EFI_IMAGE_REL_BASED_DIR64 fixups are added to the .reloc section for
> > the GOT entry of 'n'?
> >
> > int n;
> > int f () { return n; }
> > int g () { return n; }
> > int h () { return n; }

[Steven]: If the above global " n " need GOTPCREL type relocation. It should need only once EFI_IMAGE_REL_BASED_DIR64 fixups in my code.

> 
> 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.

One important thing worthy to mention that our gcc link script (GccBase.lds) has forced the GOT related sections , e.g. '.got', '.got.plt' , into .text section. So, all the GOT relocation fixup target .text section in fact.

I find below article help me a lot to understand some PIC simple relocation types. Hope it also can help you. I wish Eli, the author of below articles, could be invited as one author of x86_64 ABI spec, which will surely make the spec be more readable to other domain developers. :) 
Position Independent Code (PIC) in shared libraries 
http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/
Position Independent Code (PIC) in shared libraries on x64 
http://eli.thegreenplace.net/2011/11/11/position-independent-code-pic-in-shared-libraries-on-x64

>
> All in all, I think supporting GOT based relocations is a can of
> worms, and I would prefer to get rid of them completely if we can
> (i.e., using hidden visibility even for LTO, I have a fix for that I
> will sent out separately)
>
[Steven]: I agree we should try to avoid generating complex relocation type code for Uefi. But to make Uefi code build more portable to various version compilers and linker, I think it is still necessary to support these GOT based relocations. 
I've tested the GenFw new relocation types support with both GCC5/GCC49 (with default visibility) and CLANG38 in my branch in before. It can works. I suggest we could just keep these code there for reference.


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522