Re: [PATCH v2] BaseTools/GenFw: Add X64 GOTPCREL Support to GenFw

[Zenith432 <zenith432@users.sourceforge.net>]

It's a byproduct of aggressive GCC optimization for size -Os

GCC's code generator loads extern symbol addresses from the GOT when they produce smaller code.

1) When passing a pointer to an extern function as a non-register argument to another function it uses pushq instruction

pushq function@GOTPCREL(%rip)

This is shorter code than computing the address of function in register using leaq instruction, then pushing register.  It also saves the use of a register.

There are 5 instances of this construct in MdeModulePkg when building OvmgPkgX64.dsc, but I don't have my notes to list them here.

2) When doing pointer arithmetic on extern symbols using addq, subq, cmpq with operand stored in the GOT.

This code in
MdeModulePkg/Core/Pei/PeiMain/PeiMain.c - ShadowPeiCore

  return (PEICORE_FUNCTION_POINTER)((UINTN) EntryPoint + (UINTN) PeiCore - (UINTN) _ModuleEntryPoint);

emits a subq from the GOT entry for _ModuleEntryPoint.

The way things stand today is that when doing non-LTO GCC build,

#pragma GCC push visibility("hidden")

tells the compiler not to assume the existence of GOT entries for extern symbols and eliminates all GOT loads.

For the LTO build, it was found that this breaks the build.  So the pragma is active only for non-LTO build.

For LTO build it was found that all above instances of GOT loads in MdeModulePkg disappear due to different code generation selected by LTO.

However, LTO build (without the pragma) can still emit GOT loads to carry out pointer arithmetic done on extern symbols.  I have sample of this which is not in EDK2 codebase, and I hope to make a standalone test case of it.

My reasoning for adding this capability to GenFw is similar to the reasoning here

https://bugzilla.tianocore.org/show_bug.cgi?id=955

which is that if the latter build stage (GenFw) can handle anything GCC + binutils-ld throw it then it's not necessary to find the right compiler tweak to suppress the generation of unhandled product anymore.

As a side note, I tested that my patch to GenFw works right on all the GOTPCRELs emitted in build of OvmfPkgX64.dsc.

--------------------------------------------
On Fri, 6/8/18, Andrew Fish <afish@apple.com> wrote:

 Subject: Re: [edk2] [PATCH v2] BaseTools/GenFw: Add X64 GOTPCREL Support to GenFw
 To: "Zenith432" <zenith432@users.sourceforge.net>
 Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>, "LimingGao" <liming.gao@intel.com>
 Date: Friday, June 8, 2018, 7:02 AM
 
 Zenith,
 
 Stupid question, I'm not trying to
 derail the code review.....
 
 In a static lib world like EFI, I can't
 figure out why we need support for GOT PC REL addressing
 modes? I say that as I would think they would be relocation
 entries in object files, and then the final link would
 happen and these relocation types would not be required in
 the final executable? Seems like the linker, at link time,
 would know the relative offset for all the static libraries
 that got linked together (edk2 build) and there is no need
 for a relocation. 
 
 So I want to make sure this is not an
 issue caused by the wrong linker flags (emitting relocation
 for dynamic libs that is not supported in EF)? I'll freely
 admit there could be some circumstances I don't understand
 that require this support, but I just want to make sure we
 understand why we need to do it. Or maybe I'm missing
 something fundamental?