mirror of https://github.com/acidanthera/audk.git
051ef932bd
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> |
||
|---|---|---|
| .. | ||
| Bin | ||
| BinWrappers | ||
| Conf | ||
| Plugin | ||
| Scripts | ||
| Source | ||
| Tests | ||
| UserManuals | ||
| .gitignore | ||
| BuildEnv | ||
| Edk2ToolsBuild.py | ||
| GNUmakefile | ||
| Makefile | ||
| ReadMe.rst | ||
| basetools_calling_path_env.yaml | ||
| basetools_path_env.yaml | ||
| get_vsvars.bat | ||
| set_vsprefix_envs.bat | ||
| toolsetup.bat | ||
ReadMe.rst
:: Note: New build instructions are available. It is recommended to start with the new instructions if learning how to build edk2 and/or BaseTools for the first time. This page is retained for reference. New instructions: `Build Instructions`_ .. _`Build Instructions`: https://github.com/tianocore/tianocore.github.io/wiki/Build-Instructions This directory contains the EDK II build tools and template files. Templates are located in the Conf directory, while the tools executables for Microsoft Windows Operating Systems are located in the Bin\\Win32 directory, other directory contains tools source. Build step to generate the binary tools --------------------------------------- Windows/Visual Studio Notes =========================== To build the BaseTools, you should run the standard vsvars32.bat script from your preferred Visual Studio installation or you can run get_vsvars.bat to use latest automatically detected version. In addition to this, you should set the following environment variables:: * EDK_TOOLS_PATH - Path to the BaseTools sub directory under the edk2 tree * BASE_TOOLS_PATH - The directory where the BaseTools source is located. (It is the same directory where this README.rst is located.) After this, you can run the toolsetup.bat file, which is in the same directory as this file. It should setup the remainder of the environment, and build the tools if necessary. Unix-like operating systems =========================== To build on Unix-like operating systems, you only need to type ``make`` in the base directory of the project. Ubuntu Notes ============ On Ubuntu, the following command should install all the necessary build packages to build all the C BaseTools:: sudo apt install build-essential uuid-dev