mirror of https://github.com/acidanthera/audk.git
ecbaa856da
Adds support for the following X64 ELF relocations to GenFw R_X86_64_GOTPCREL R_X86_64_GOTPCRELX R_X86_64_REX_GOTPCRELX Background: The GCC49 and GCC5 toolchains use the small pie model for X64. In the small pie model, gcc emits a GOTPCREL relocation whenever C code takes the address of a global function. The emission of GOTPCREL is mitigated by several factors 1. In GCC49, all global symbols are declared hidden thereby eliminating the emission of GOTPCREL. 2. In GCC5, LTO is used. In LTO, the complier first creates intermediate representation (IR) files. During the static link stage, the LTO compiler combines all IR files as a single compilation unit, using linker symbol assistance to generate code. Any global symbols defined in the IR that are not referenced from outside the IR are converted to local symbols - thereby eliminating the emission of GOTPCREL for them. 3. The linker (binutils ld) further transforms any GOTPCREL used with the movq opcode to a direct rip-relative relocation used with the leaq opcode. This linker optimization can be disabled with the option -Wl,--no-relax. Furthermore, gcc is able to emit GOTPCREL with other opcodes - pushq opcode for passing arguments to functions. - addq/subq opcodes for pointer arithmetic. These other opcode uses are not transformed by the linker. Ultimately, in GCC5 there are some emissions of GOTPCREL that survive all these mitigations - if C code takes the address of a global function defined in assembly code - and performs pointer arithmetic on the address - then the GOTPCREL remains in the final linker product. A GOTPCREL relocation today causes the build to stop since GenFw does not handle them. It is possible to eliminate any remaining GOTPCREL emissions by manually declaring the global symbols causing them to have hidden visibility. This patch is offered instead to allow GenFw to handle any residual GOTPCREL. Cc: Shi Steven <steven.shi@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Zenith432 <zenith432@users.sourceforge.net> Reviewed-by: Liming Gao <liming.gao@intel.com> |
||
|---|---|---|
| .. | ||
| Bin | ||
| BinWrappers | ||
| Conf | ||
| Scripts | ||
| Source | ||
| Tests | ||
| UserManuals | ||
| gcc | ||
| .gitignore | ||
| BuildEnv | ||
| BuildNotes.txt | ||
| GNUmakefile | ||
| Makefile | ||
| ReadMe.txt | ||
| building-gcc.txt | ||
| get_vsvars.bat | ||
| set_vsprefix_envs.bat | ||
| toolsetup.bat | ||
ReadMe.txt
This directory contains the next generation of EDK II build tools and template files. Templates are located in the Conf directory, while the tools executables for Microsoft Windows 32-bit Operating Systems are located in the Bin\Win32 directory, other directory contatins tools source. 1. 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.txt is located.) * PYTHON_FREEZER_PATH - Path to where the python freezer tool is installed 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. Please also refer to the 'BuildNotes.txt' file for more information on building under Windows. === 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-get install build-essential uuid-dev === Python sqlite3 module === On Windows, the cx_freeze will not copy the sqlite3.dll to the frozen binary directory (the same directory as build.exe and GenFds.exe). Please copy it manually from <PythonHome>\DLLs. The Python distributed with most recent Linux will have sqlite3 module built in. If not, please install sqlit3 package separately. 26-OCT-2011