Tianocore/edk2.git/BaseTools/Scripts/GccBase.lds, branch trunk

Renormalized end-of-lines from master@27b044605cd5f6b33a3d231576003850b3fe305b

2024-06-04T03:43:08+00:00

BaseTools: make sure the got is empty

2023-06-01T10:53:35+00:00

Add ASSERT()s that .got and .got.plt sections are empty to linker scripts for gcc and clang. Suggested-by: Ard Biesheuvel Signed-off-by: Gerd Hoffmann Reviewed-by: Liming Gao Reviewed-by: Rebecca Cran

BaseTools: Remove COMMON section from the GCC discard list

2021-07-26T07:30:11+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2507 The COMMON section is used by OpenSSL assembly-optimized crypto functions. OpenSSL assembly code is auto-generated from the submodule and cannot be modified to remove dependence on the COMMON section. The default -fno-common compiler flag should still prevent variable from being emitted into the COMMON section. Cc: Ard Biesheuvel Cc: Bob Feng Cc: Liming Gao Signed-off-by: Christopher Zurcher Reviewed-by: Liming Gao Acked-by: Jiewen Yao

BaseTools: Replace BSD License with BSD+Patent License

2019-04-09T16:10:20+00:00

https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney Reviewed-by: Bob Feng

BaseTools/Scripts: fix GccBase.lds line endings

2017-05-28T12:07:02+00:00

Replace a line ending that was introduced inadvertently by a recent commit with the correct Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel

BaseTools/Scripts: discard .gnu.hash section in GCC builds

2017-05-24T13:09:39+00:00

Some builds of GCC/binutils will default to using the GNU flavor of the symbol hash table, and will emit it into a section called .gnu.hash rather than .hash. We have no use for its contents, and GenFw ignores it anyway, so it shouldn't really matter what we do with it. However, due to a workaround for AARCH64 we have in GenFw to deal with older GCCs that corrupt section-based relocations when merging sections during the final link, we need the ELF and PE/COFF views of the binary to be identical. Since we don't place the .gnu.hash section explicitly, it may end up at the beginning of the ELF binary, causing other sections to be shifted in the ELF view but not in the PE/COFF view. So let's add .gnu.hash to the GCC linker script. We don't care about its contents so add it to the /DISCARD/ section. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Tested-by: Leif Lindholm Reviewed-by: Liming Gao

BaseTools: GCC: move most AutoGen.obj contents back to .data section

2017-02-24T10:27:56+00:00

The generated AutoGen.c files mostly contain read-only data, but due to lacking annotations, all of it is emitted into the .data section by the compiler. Given that GUIDs are UEFI's gaffer tape, having writable GUIDs is a security hazard, and this was the main rationale for putting AutoGen.obj in the .text section. However, as it turns out, patchable PCDs are emitted there as well, which can legally be modified at runtime. So update the wildcard pattern to only match g...Guid sections, and move everything else back to .data (Note that this relies on -fdata-sections, without that option, everything is emitted into .data) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Tested-by: Laszlo Ersek Reviewed-by: Liming Gao Fixes: 233bd25b000f92fc4bbe181fa48edcd72808de8e [lersek@redhat.com: add reference to previous commit being fixed up] Signed-off-by: Laszlo Ersek

BaseTools/GccBase.lds: don't copy RELA section to PE/COFF

2016-08-22T10:26:42+00:00

The CLANG38 toolchain creates a PIE binary at link time. This is necessary since the LTO code generation may otherwise result in code that cannot execute correctly when loaded above 2 GB. PIE executables contain a RELA section consisting of dynamic relocation entries that are intended for consumption by the loader at runtime. For this reason, it has the SHF_ALLOC attribute set by default, and will be identified by GenFw as a section that needs to be copied into the PE/COFF binary, resulting in waste of space since the PE/COFF loader does not use this data at all. So mark the RELA section as informational: this will prevent the linker from setting the SHF_ALLOC attribute, causing GenFw to ignore it. DxeCore.efi before: Detected 'X64' type PE/COFF image consisting of 3 sections Section alignment: 0x40 File alignment: 0x40 Section '.text' @ 0x00000240 File offset: 0x240 Virtual size: 0x21000 Raw size: 0x21000 Section '.data' @ 0x00021240 File offset: 0x21240 Virtual size: 0x3640 Raw size: 0x3640 Section '.reloc' @ 0x00024880 File offset: 0x24880 Virtual size: 0x280 Raw size: 0x280 DxeCore.efi after: Detected 'X64' type PE/COFF image consisting of 3 sections Section alignment: 0x40 File alignment: 0x40 Section '.text' @ 0x00000240 File offset: 0x240 Virtual size: 0x1f440 Raw size: 0x1f440 Section '.data' @ 0x0001f680 File offset: 0x1f680 Virtual size: 0x3640 Raw size: 0x3640 Section '.reloc' @ 0x00022cc0 File offset: 0x22cc0 Virtual size: 0x280 Raw size: 0x280 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Liming Gao

BaseTools GCC: drop GNU notes section from EFI image

2016-08-02T08:54:11+00:00

Recent versions of GNU ld automatically emit a .notes section into the ELF binary containing a build id. Since this is an allocatable section by default, it will be identified by GenFw as a section that requires PE/COFF conversion, which may cause sections to be moved around unexpectedly. So retain the section, but tag it as INFO, which tells the linker that it should not be accounted for in the binary's memory layout. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Acked-by: Jordan Justen Reviewed-by: Liming Gao

Preserve hii section in GCC binaries

2016-07-26T02:21:45+00:00

According to UEFI spec: Once an image is loaded, LoadImage() installs EFI_HII_PACKAGE_LIST_PROTOCOL on the handle if the image contains a custom PE/COFF resource with the type 'HII'. The protocol's interface pointer points to the HII package list which is contained in the resource's data. This is controlled by the UEFI_HII_RESOURCE_SECTION define in the INF file. When present the HII resource is linked with the module binary. Unfortunately GCC-built binaries have been stripping the .hii section entirely. See "[edk2] HII gEfiHiiPackageListProtocolGuid problem with GCC48(VS2012x86 works)" http://thread.gmane.org/gmane.comp.bios.tianocore.devel/13438 http://thread.gmane.org/gmane.comp.bios.tianocore.devel/14899 This patch tells the linker to preserve the .hii sections Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Palmer Acked-by: Laszlo Ersek Tested-by: Bruce Cran Reviewed-by: Bruce Cran Reviewed-by: Yonghong Zhu Reviewed-by: Liming Gao