On Tue, Dec 11, 2018 at 10:37:15AM +0100, Ard Biesheuvel wrote: > We currently permit R_ARM_GOT_PREL relocations in the ELF32 conversion > routines, under the assumption that relative relocations are fine as > long as the section layout is the same between ELF and PE/COFF. > > However, as is the case with any proxy generating relocation, it is > up to the linker to emit an entry in the GOT table and populate it > with the correct absolute address, which should also be fixed up at > PE/COFF load time. Unfortunately, the relocations covering the GOT > section are not emitted into the static relocation sections processed > by GenFw, but only in the dynamic relocation section as a R_ARM_RELATIVE > relocation, and so GenFw fails to emit the correct PE/COFF relocation > data for GOT entries. > > Since GOT indirection is pointless anyway for PE/COFF modules running > in UEFI context, let's just drop the references to R_ARM_GOT_PREL from > GenFw, resulting in a build time failure rather than a runtime failure > if such relocations do occur. > > Cc: Bob Feng <bob.c.f...@intel.com> > Cc: Liming Gao <liming....@intel.com> > Cc: Leif Lindholm <leif.lindh...@linaro.org> > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org> Ouch. This sounds like the best move for now. But how do we deal with builds that actually break? > --- > > Without this patch, CLANG38 builds of ArmVirtQemuKernel-ARM (in LTO mode) > succeed, but the resulting binaries are broken. This is due to the fact that > the PIE linker running in LTO mode insists on emitting GOT based relocations, > while we don't have the code to fix up the contents of the GOT. This change > puts it in line with the AARCH64 build of the same platform/toolchains, > which chokes on GOT based relocations as well. Since the use of the PIE > linker is a peculiarity of ArmVirtQemuKernel/ArmVirtXen, and the fact that > it is impossible to prevent the linker from emitting GOT based relocations, > let's not go out of our way to fix it in the tools, but just drop CLANG38 > support from those platforms. > > BaseTools/Source/C/GenFw/Elf32Convert.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/BaseTools/Source/C/GenFw/Elf32Convert.c > b/BaseTools/Source/C/GenFw/Elf32Convert.c > index 3d7de6d5c123..23e8065756e6 100644 > --- a/BaseTools/Source/C/GenFw/Elf32Convert.c > +++ b/BaseTools/Source/C/GenFw/Elf32Convert.c > @@ -837,7 +837,6 @@ WriteSections32 ( > case R_ARM_LDC_PC_G0: > case R_ARM_LDC_PC_G1: > case R_ARM_LDC_PC_G2: > - case R_ARM_GOT_PREL: > case R_ARM_THM_JUMP11: > case R_ARM_THM_JUMP8: > case R_ARM_TLS_GD32: > @@ -964,7 +963,6 @@ WriteRelocations32 ( > case R_ARM_LDC_PC_G0: > case R_ARM_LDC_PC_G1: > case R_ARM_LDC_PC_G2: > - case R_ARM_GOT_PREL: > case R_ARM_THM_JUMP11: > case R_ARM_THM_JUMP8: > case R_ARM_TLS_GD32: > -- > 2.19.2 > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel