BaseTools/GenFw X64: Detect GOTCPRELX relaxations applied by LLD

GenFw relies on static ELF relocation tables emitted by the linker (via
the --emit-relocs command line switch). These are different from the
dynamic relocations that a dynamic loader uses: static relocations are
emitted by the compiler/assembler, and consumed by the linker to
construct the executable. Only when the load address is a priori unknown
are dynamic relocations emitted, by the linker, in a format that the
dynamic loader can consume.

This distinction is relevant because only dynamic relocations cover the
GOT, and so GOT based indirections are better avoided. Unfortunately,
there are cases where the toolchain insists on emitting GOT based symbol
references, and so we have to deal with them in one of 2 ways:

- replace GOT based symbol references with direct references, so that
  the GOT entries themselves are no longer used, and can be ignored when
  generating the PE/COFF relocation tables (AARCH64 and RISCV64 take
  this approach);

- infer the locations of the GOT slots from the references appearing in
  the code, and emit PE/COFF relocations for them so that their contents
  will be fixed up appropriately.

The latter is the approach taken by GenFw for x86_64, which is the only
feasible approach for its ISA, given that GOT slots can be used as
memory operands in many different types of instructions, not all of
which can be converted straight-forwardly.

E.g.,

   movq   foo@GOTPCREL(%rip), %rax

can always be converted into

   leaq   foo(%rip), %rax

whereas

   cmpq   foo@GOTPCREL(%rip), %rax

can only be converted under the 32-bit position dependent code model,
into

   cmpq   $foo, %rax

and so the GOT references cannot be elided when generating position
independent code, which is what GenFw requires.

To remove the need for the linker to guess where the instructions start,
the ELF psABI for x86_64 specifies a couple of relaxable alternatives
for GOTPCREL, which are used to annotate particular classes of GOT
referencing instructions that may be relaxed to their non-GOT
counterparts.

There is no specification for what --emit-relocs is supposed to produce,
or whether or not its output is supposed to reflect such relaxations.
ld.bfd and LLD behave differently in this regard, and the latter may
emit R_X86_64_REX_GOTPCRELX relocations for MOV instructions that it
already has relaxed into LEA instructions. This means the displacement
in the instruction no longer refers to the GOT slot, but directly to the
object itself, and emitting a relocation is not only unnecessary, but
also harmful as the PE/COFF loader will corrupt the object when it
applies the relocations at startup.

Under the position independent code model, the only relaxation that the
linker could have applied for a R_X86_64_REX_GOTPCRELX relocation is MOV
to LEA, so detect whether the instruction is already LEA, and ignore the
relocation if that is the case.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

1 files changed, 10 insertions, 1 deletions

diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c b/BaseTools/Source/C/GenFw/Elf64Convert.c
index 9d04fc612e..897045b2be 100644
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -1482,9 +1482,18 @@ WriteSections64 (
               - (SecOffset - SecShdr->sh_addr));

             VerboseMsg ("Relocation:  0x%08X", *(UINT32 *)Targ);

             break;

+          case R_X86_64_REX_GOTPCRELX:

+            //

+            // This is a relaxable GOTPCREL relocation, and the linker may have

+            // applied this relaxation without updating the relocation type.

+            // In the position independent code model, only transformations

+            // from MOV to LEA are possible for REX-prefixed instructions.

+            //

+            if (Targ[-2] == 0x8d) { // LEA

+              break;

+            }

           case R_X86_64_GOTPCREL:

           case R_X86_64_GOTPCRELX:

-          case R_X86_64_REX_GOTPCRELX:

             VerboseMsg ("R_X86_64_GOTPCREL family");

             VerboseMsg ("Offset: 0x%08X, Addend: 0x%08X",

               (UINT32)(SecOffset + (Rel->r_offset - SecShdr->sh_addr)),