BaseTools/GenFw ARM: don't permit R_ARM_GOT_PREL relocations
authorArd Biesheuvel <ard.biesheuvel@linaro.org>
Tue, 11 Dec 2018 09:23:20 +0000 (10:23 +0100)
committerArd Biesheuvel <ard.biesheuvel@linaro.org>
Wed, 12 Dec 2018 07:36:59 +0000 (08:36 +0100)
commit0d68ce514b922f887da28c2a12b8d37cf23903f0
tree60d758752b182f0d493d049cc68d411fdfd6f47e
parente07092edca8442db4a941dbeea0cd196c7bf8ec9
BaseTools/GenFw ARM: don't permit R_ARM_GOT_PREL relocations

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.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BaseTools/Source/C/GenFw/Elf32Convert.c