summaryrefslogtreecommitdiffstats
path: root/BaseTools/Conf
Commit message (Collapse)AuthorAgeFilesLines
* BaseTools: Add /DRIVER to CLANGPDB link flagsDionna Glaze2025-02-031-6/+6
| | | | | | This quiets the warning reported in Issue #10637. Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
* BaseTools/tools_def: Remove no-warn-rwx-segments linker optionsArd Biesheuvel2025-02-021-8/+3
| | | | | | | | | | | | | | The linker option 'no-warn-rwx-segments' breaks both the LLVM linker and versions of the binutils ld.bfd linker prior to 2.39. Now that the ELF image is made up of separate R-X and RW- segments, this warning is no longer emitted and so there is no longer a need to suppress it either. While at it, move GCC_DLINK_FLAGS_COMMON (which is not common but only used by Ia32 and X64) into its only user so it can be dropped. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* BaseTools/Scripts: Merge GCC and Clang ELF linker scriptsArd Biesheuvel2025-02-021-2/+1
| | | | | | | | | | | | | | The original reason for creating a separate version of the ELF linker script for Clang was the difference between COMMONPAGESIZE and MAXPAGESIZE, which can we provided on the command line to the respective linkers (ld.bfd versus lld). That difference no longer exists, and both use COMMONPAGE_SIZE. So there is no longer a need to maintain a fork, which has already been going out of sync with the original for no good reason. So merge the two and call it GccBase.lds Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* BaseTools/tools_def: Use no-warn-rwx-segments only for GCC5Ard Biesheuvel2025-02-011-3/+3
| | | | | | | | | | | | | The command line option --no-warn-rwx-segments was added to the linker command line for all GCC family builds on ARM and AARCH64, including CLANGDWARF and GCC49 and older, none of which are intended for use with linkers that actually understand this option. So instead, move it to the GCC5 DLINK FLAGS definitions for ARM and AARCH64 (which are inherited by the versionless GCC which is intended to replace GCC5 at some point). Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* BaseTools: Break Build on Linker WarningsOliver Smith-Denny2025-01-221-14/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | Today VS2022 and GCC are set to treat all compiler warnings as errors and break the build. However, linker warnings for both do not break the build. There are critical errors that can be treated as warnings as the linker, such as not finding the module entry point and use a default address as the entry point. This will cause a runtime crash for something that should be caught at build time. This commit adds /WX to VS2022's DLINK_FLAGS and --fatal-warnings to GCC's DLINK_FLAGS for IA32, X64, ARM, and AARCH64 in order to break the build on linker warnings. VS2022 linker warning 4210 is ignored for all builds because it checks for static initializers and the linking of the VCRuntime. edk2 never links the VCRuntime (except for HOST_APPLICATIONs) and so the presence of static initializers will always cause this warning, even when the edk2 code calls these initializers that would otherwise be called in the _CRT_INIT function of the VCRuntime. At the time of this commit, it only fails in CryptoPkg for building OpenSSL, but could fail anywhere a static initializer is used. Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
* BaseTools/Conf: Simplify VS20xx HOST_APPLICATION buildsMichael D Kinney2025-01-212-1/+32
| | | | | | | | | | | | | | | | | | Add Empty_C_File_Host_Application_Build.c to BaseTools/Conf that is a C source file with only comments that is used to compile into an OBJ file using CC_FLAGS for a HOST_APPLICATION module and the OBJ is passed into the VS20xx DLINK action to provide the context required to select the correct default windows application libraries. Update build_rule.template to compile the empty C file and generate OBJ in the OUTPUT_DIR of the HOST_APPLICATION component and use the OBJ in the DLINK action. This simplifies CC_FLAGS and DLINK_FLAGS for all modules of type HOST_APPLICATION. Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: build_rule.template generate a different dll for wholearchive.Aaron Pop2025-01-151-2/+4
| | | | | | | | | | When running the /wholearchive test build, generate the test .dll as a different filename to prevent the system holding onto the dll file too long and generating a build error that the actual dll cannot be found. Remove the temporary file after it was generated because the successful completion of the link command is the test case. Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
* BaseTools: Update alignment for entry seg for ClangDhaval2024-12-111-2/+3
| | | | | | | | | | | | | | | | It does 3 things: 1. Use separate linker file for clang vs GCC for RISCV64. 2. Use common page size instead of max page to ensure -z option align values are properly applied. 3. Enforce alignment for .entry segment as per -z option. When we want to have -z option aligned images, clang while alignes .text and .data segments correctly, .entry segment is by default not aligned unless explicitly specified. This patch makes it explicit to clang that entry seg should also be aligned to requirements. Somehow GCC does not require such explicit entry. Hence detachiong both ld files. Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com>
* BaseTools: Add VS2022 XIPFLAGSOliver Smith-Denny2024-12-103-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BaseTools has a limitation that modules in FVs that are force rebased must have the same file and section alignment. This is intended for XIP modules. VS2019 and previous VS toolchains did not set 4k section alignment, but VS2022 does, in order for memory protections to be applied to images. This causes issues when building SEC and PEI modules on VS2022 as the file alignment is 0x20 but the section alignment is 0x1000, so BaseTools will fail to generate the FV. One option is to set the file alignment to 0x1000 for all of these files, but that is a large waste of space and is not feasible on some platforms that have limited flash space. The other option is to selectively set 0x20 as the section alignment for SEC and PEI modules, which is the approach GCC ARM/AARCH64 took. This is only an issue for building 64-bit PEI on x86 currently, as other architectures are not supported by VS2022 in edk2 yet. For IA32, the section alignment is set to 0x20 and so it matches the file alignment, however x64 PEI uses the X64 DLINK flags which have 0x1000 set. For other architectures that don't have the PEI/DXE architecture split, this is also an issue. This commit is required to use VS2022 as the default CI in edk2, as OvmfPkgX64.dsc will fail to build. Any platform with 64-bit PEI also requires this. This commit also updates CryptoPkg.dsc and SecurityPkg.dsc as they are setting custom section alignments. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
* BaseTools: Add /WHOLEARCHIVE for VS2022 BuildsOliver Smith-Denny2024-12-101-1/+1
| | | | | | | | | | | | | VS2022's DLINK2_FLAGS (containing only /WHOLEARCHIVE) was commented out during upstreaming, due to some downstream platform issues when /WHOLEARCHIVE was set. This does not prove an issue for edk2 and is what is used for earlier versions of VS, so is added here for VS2022. If platforms see issues, bugs should be filed on edk2 (or fixed in the platform if applicable). Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
* BaseTools: Remove -Wno-unneeded-internal-declaration from CLANGDWARFMike Beaton2024-10-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Subsequent to updating the 'null' DEBUG macro to explicitly discard its expression, it is possible to remove this warning suppression from CLANGDWARF and still successfully compile its RELEASE build. Note that CLANGPDB did and does not have this warning suppressed, and so before updating the 'null' DEBUG macro, CLANGPDB RELEASE was not building successfully in recent versions of clang, but was stopping with the error: .../edk2/OvmfPkg/VirtioSerialDxe/VirtioSerial.c:28:22: error: variable &apos;EventNames&apos; is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration] STATIC CONST CHAR8 *EventNames[] = { ^ This change makes the two CLANG variants match with respect to this warning, and leaves the warning enabled which is considered a benefit as it has the potential to catch real coding errors Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
* BaseTools/tools_def ARM: Disable stack protector with CLANGDWARFArd Biesheuvel2024-09-181-1/+1
| | | | | | | | | | | | | | | Clang insists on emitting a movt/movw pair into the function pro/epilogues to load the stack protector reference value from memory, and this movt/movw pair may turn out non-consecutively in the instruction stream. The resulting symbol reference cannot be fixed up by GenFw, as PE/COFF always treats movt/movw as a pair, and the ELF-to-PE conversion will therefore fail. Just disable the stack protector when using CLANGDWARF. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* BaseTools: Add Stack Cookie Support to MSVC and GCC IA32/X64/ARM/AARCH64Taylor Beebe2024-09-131-31/+34
| | | | | | | This patch directs MSVC and GCC to build stack cookie support into binaries. Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* BaseTools: Disable MSVC volatileMetadata for VS2019 and VS2022 for X64Ashraf Ali2024-09-061-6/+6
| | | | | | | | | | | | | | | Starting with Visual Studio 2019 version 16.10, the /volatileMetadata option is enabled by default when generating x64 code. This patch disables the /volatileMetadata option for x64 builds in both VS2019 and VS2022. We observed a slight increase in used space for the Firmware volumes in VS2019. Upon investigation, we found that VS2019 version 16.10 enabled this feature by default. Disabling /volatileMetadata helps reduce the used space by approximately 3.5KB by considering the 2 Firmware volumes (2KB uncompressed FV and 1.5KB of compressed FV) Signed-off-by: Ashraf Ali <ashraf.ali.s@intel.com>
* BaseTools: fix build error with TOOL_CHAIN_TAG VS2015 & VS2015x86wilson_chen2024-07-301-2/+2
| | | | | | | | | | | | | | | | | | Start the build with TOOL_CHAIN_TAG VS2015 by launch: Build -t VS2015 ERROR: Would get following build error message: 'c:\Program' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: '"c:\Program Files\Windows Kits\8.1\bin\x86\\rc.exe' : return code '0x1' Stop. Fix the build error, Tested : TOOL_CHAIN_TAG = VS2015 (>Build -t VS2015) TOOL_CHAIN_TAG = VS2015x86 (>Build -t VS2015x86) Signed-off-by: wilson_chen <wilson_chen@phoenix.com>
* BaseTools/tools_def CLANGDWARF: Always use -Oz in RELEASE modeArd Biesheuvel2024-07-281-3/+3
| | | | | | | | | | | | | | | | | | | | GCC5 and CLANGDWARF for IA32/X64 use -Os or -Oz as the optimization level, which agressively optimizes for the smallest possible object code. On AARCH64, RISCV64 and ARM, we use -O3 instead, which results in considerable image bloat, to the point where the Raspberry Pi 4 build in edk2-platforms does not even build with -D SECURE_BOOT_ENABLE. So let's align CLANGDWARF across all architectures, and use -Oz throughout. Note that O3 is still used for the linker, which build in LTO mode and therefore performs some code generation as well. This is deliberate: LLD does not support the Os/Oz optimization levels at all, and using Oz for the compile pass is sufficient to reduce the code size substantially. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* BaseTools: Move GnuNoteBti.bin to BaseToolsOliver Smith-Denny2024-07-231-1/+1
| | | | | | | | | This patch moves GnuNoteBti.bin from ArmPkg to BaseTools as it is used during the build by GCC. This removes an unnecessary dependency on ArmPkg from BaseTools and keeps build related files in BaseTools. Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* BaseTools: Move GccLto Files to BaseToolsOliver Smith-Denny2024-07-231-12/+12
| | | | | | | | | This moves the GccLto files from ArmPkg to BaseTools as they are files that are only used in the build. This removes an artificial dependency on ArmPkg from BaseTools and keeps build related files in BaseTools. Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* BaseTools: Remove fno-plt from LoongArch CC flagsChao Li2024-07-121-1/+1
| | | | | | | | | | | | | | Static relocation types have been handled in GenFw if using the PIC, and the CC flags not enable `fno-pic` by default. The option `fno-plt` is not necessary, as is not created by defualt in edk2(static linking) regardless of wether `fplt` is used or not, so remove this option from the LoongArch common CC flags. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Chao Li <lichao@loongson.cn>
* BaseTools: Add VS2022 support.Matthew Carlson2024-07-081-5/+160
| | | | | | | | Adding tools_def for VS2022. Update WindowsVsToolChain to support VS2022. Update set_vsPrefix_envs and toolsetup and edksetup to support VS2022. Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
* BaseTools/Conf/target.template: Use VS2019 as default tool chainMichael Kubacki2023-11-291-5/+5
| | | | | | | | | | | | | | | Updates the default tool chain from VS2015x86 to VS2019. This is the VS tool chain used in CI and more likely to be installed on developer's systems. This is used in stuart commands when a toolchain is not explicitly specified. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Yuwei Chen <yuwei.chen@intel.com>
* BaseTools/tools_def: drop -mgeneral-regs-only for AArch64 CLANGDWARFYeping Song2023-11-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Commit 0df6c8c157af9 ("BaseTools/tools_def AARCH64: avoid SIMD registers in XIP code") adds -mgeneral-regs-only to GCC_AARCH64_CC_XIPFLAGS, in order to avoid a bug present in certain versions of GCC. This was never a problem for clang. That's given the history of what the problem is. Then we can describe how we fix it: Change *_CLANGDWARF_AARCH64_CC_XIPFLAGS to set the required -mstrict-align option instead of importing the whole GCC variable. Signed-off-by: Yeping Song <quic_yepings@quicinc.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
* BaseTools: drop tautological warning overrides for CLANGDWARFLeif Lindholm2023-08-291-1/+1
| | | | | | | | | | | | | | | | The CLANGDWARF profile sets both -Wno-tautological-compare and -Wno-tautological-constant-out-of-range-compare, but this prevents compile-time detection of certain errors. Drop these flags. Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools/tools_def: Add CLANGDWARF support for RISC-VSunil V L2023-07-311-0/+53
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4478 Add tools_def definitions to support CLANGDWARF toolchain for RISC-V. This uses clang and the llvm LLD linker. This helps people by not requiring to install multiple cross compilers for different architectures. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Ard Biesheuvel <ardb@kernel.org> # Debian clang version 14.0.6 Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools/tools_def: Add "-fno-unwind-tables" to GCC5_RISCV64_CC_FLAGSSunil V L2023-06-271-1/+1
| | | | | | | | | | | | | | | | | | | | gcc-13 for RISC-V enables unwind tables by default similar to ARM64. This generates .eh_frame_hdr section which is not handled well by GenFw causing failures. Disable the unwind tables by adding -fno-unwind-tables flag similar to [1]. [1] - https://github.com/tianocore/edk2/commit/cbf00651eda6 Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Andrei Warkentin <andrei.warkentin@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools: add -fdirect-access-external-data to clang pie buildsGerd Hoffmann2023-06-011-3/+3
| | | | | | | | Tell clang to not use external (via got) references for data access. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
* BaseTools/tools_def: Disable overzealous unused variable warning on ClangArd Biesheuvel2023-05-121-1/+1
| | | | | | | | | | | | | The warnings Clang emits when enabling -Wunneeded-internal-declaration (which is part of -Wall) are generating false positives for variables whose size gets taken but are not referenced beyond yet. This may happen legitimately in debug code, so let's disable this warning for Clang, rather than tiptoe around it in the code. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* BaseTools/tools_def: Drop ref to undefined CLANGDWARF_ARM_PREFIXArd Biesheuvel2023-05-121-1/+1
| | | | | | | | | | | | | | When using CLANGDWARF to build for the ARM architecture, objcopy is references via the wrong environment variable, resulting in the wrong llvm-objcopy to be used (if one exists), or the build to fail (if CLANGDWARF_BIN points to the only available instance) So use CLANGDWARF_BIN instead, which was what was intended. Fixes: ecbc394365f50f3c ("BaseTools: Set CLANGDWARF RC path ...") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools: Revert Set the CLANGDWARF OBJCOPY path in tools_def.templateRebecca Cran2023-05-111-4/+0
| | | | | | | | | | This reverts commit 11f62f4cc09f16d265da1a737dabfd8ed65f8c00. While GCC uses objcopy for the OBJCOPY command, it's not needed for the CLANGDWARF toolchain and can be left as echo. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Ard BIesheuvel <ardb@kernel.org>
* BaseTools: Remove the CLANGCC build rule for Hii-Binary-Package.UEFI_HIIRebecca Cran2023-05-101-1/+1
| | | | | | | | | | The build rule for Hii-Binary-Package.UEFI_HII should be the same as for GCC, using $(RC) to embed the HII resource into the binary. Since the build rule defaults to GCC, just remove CLANGGCC from the section. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: Set CLANGDWARF RC path to llvm-objcopy in tools_def.templateRebecca Cran2023-05-101-4/+4
| | | | | | | | | | The llvm-rc tool is for Windows PE resources. Since the CLANGDWARF toolchain creates ELF binaries, update the RC path to be llvm-objcopy. This follows the GCC toolchain which uses objcopy for the RC path. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: Set the CLANGDWARF OBJCOPY path in tools_def.templateRebecca Cran2023-05-101-0/+4
| | | | | | | | | Set the OBJCOPY path for the CLANGDWARF toolchain to 'llvm-objcopy' to override the default of 'echo'. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: Remove BUILDRULEFAMILY from CLANGDWARF in tools_def.templateRebecca Cran2023-05-101-1/+1
| | | | | | | | | | There's only a single rule in build_rule.template for CLANGGCC, and it's incorrect. We should instead just use the rules for GCC, so remove the BUILDRULEFAMILY line for the CLANGDWARF toolchain definition. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools/Conf: Add quotes to ADDDEBUGFLAG in tools_def.txtMichael D Kinney2023-05-061-2/+2
| | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4448 Update tools_def.txt to add quotes around the file target in OBJCOPY_ADDDEBUGFLAGS for compatibility with GCC like tool chains used on Windows. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools/Conf: Align CLANGDWARF and CLANGPDB warning overridesMichael D Kinney2023-05-061-1/+1
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4447 Fix build error related to use of DEBUG_CODE_BEGIN() and DEBUG_CODE_END(). CLANGPDB requires extra warning disables for use of DebugLib.h macros. This change aligns the warning disables between CLANGDWARF and CLANGPDB. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* BaseTools/Conf/tools_def.template: Bump VERSION to 3.00Rebecca Cran2023-05-051-1/+6
| | | | | | | | | Bump VERSION to 3.00 and explain the changes made to the toolchains. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: Delete CLANG38 from tools_def.templateRebecca Cran2023-05-051-211/+22
| | | | | | | | | Clang 3.8 is a very old release and is no longer relevant. Delete the CLANG38 toolchain from tools_def.template. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: Remove CLANG35 toolchain from tools_def.templateRebecca Cran2023-05-051-88/+0
| | | | | | | | | Clang 3.5 is a very old release and is no longer relevant. Remove the CLANG35 toolchain from tools_def.template. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: As with CLANGDWARF IA32 and X64, use lld for ARM and AARCH64Rebecca Cran2023-05-051-6/+6
| | | | | | | | | | | | As with the IA32 and X64 CLANGDWARF toolchain definitions, use ld.lld for ARM and AARCH64. Add -Wl,--no-pie,--no-relax to the command line to fix linking when using lld. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: Add ARM and AARCH64 CLANGDWARF support in tools_def.templateRebecca Cran2023-05-051-0/+90
| | | | | | | | | Add ARM and AARCH64 support to CLANGDWARF in tools_def.template, copying the CLANG38 definitions. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools/Conf/tools_def.template: Add section for deprecated toolchainsRebecca Cran2023-05-051-8/+23
| | | | | | | | | | | In order to make it clear for anyone reading tools_def.template, add a section for deprecated tool chains and move GCC48, GCC49 and GCC5 into it. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* Add GCC and GCCNOLTO toolchains to tools_def.txt and update packagesRebecca Cran2023-05-051-0/+366
| | | | | | | | | | Add a 'GCC' toolchain that's a copy of the existing GCC5 definition. Add a 'GCCNOLTO' toolchain that's a copy of the existing GCC49 toolchain. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: Update VS toolchain descriptions in tools_def.txt.templateRebecca Cran2023-05-051-5/+2
| | | | | | | | | | | | | | Update the Visual Studio toolchain descriptions in tools_def.txt.template: - The WinDDK is no longer needed. - Update 3 is required for VS 2015. - VS 2005 has been removed. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: Remove EBC (EFI Byte Code) compiler definitionsRebecca Cran2023-05-051-98/+0
| | | | | | | | | | | | | | | | The edk2-stable202302 release was the last to support building EFI Byte Code drivers. Since the Intel EFI Byte Code Compiler is no longer available, a decision has been made to remove support for EBC from edk2. Remove the definitions for Intel's EBC compiler from Conf/tools_def.template. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: Remove unused IPHONE_TOOLS and SOURCERY_CYGWIN_TOOLS defsRebecca Cran2023-05-051-4/+0
| | | | | | | | | | | Remove the unused IPHONE_TOOLS and SOURCERY_CYGWIN_TOOLS definitions from Conf/tools_def.template. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: Remove VS2008-VS2013 remnantsRebecca Cran2023-05-051-12/+0
| | | | | | | | | | | Remove remnants of Visual Studio 2008-2013 support from Conf/tools_def.txt and various batch scripts. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: Remove VS2008, 2010, 2012 and 2013 toolchain definitionsRebecca Cran2023-05-051-1005/+0
| | | | | | | | | | | | | | | With recent changes, Visual Studio versions older than VS2015 are unable to build EDK2 code. To avoid confusion, remove VS2008, 2010, 2012 and 2013 toolchain definitions from Conf/tools_def.template, leaving only versions that can be used to successfully build firmware. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: Add quotes around OBJCOPY cmd in build_rule.templateRebecca Cran2023-04-251-2/+2
| | | | | | | | | | Add quotes around the OBJCOPY command in build_rule.template to fix the case where LLVM is installed on Windows in a path with spaces such as C:\Program Files\LLVM. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools/tools_def CLANGDWARF: Permit text relocationsArd Biesheuvel2023-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | We rely on PIE executables to get the codegen that is suitable for PE/COFF conversion where the resulting executables can be loaded anywhere in the address space. However, ELF linkers may default to disallowing text relocations in PIE executables, as this would require text segments to be updated at runtime, which is bad for security and increases the copy-on-write footprint of ELF executables and shared libraries. However, none of those concerns apply to PE/COFF executables in the context of EFI, which are copied into memory rather than mmap()'ed, and fixed up by the loader before launch. So pass -z notext to the LLD linker to permit runtime relocations in read-only sections. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools/Conf/tools_def: Fix linking using CLANGDWARF_IA32Rebecca Cran2023-04-051-7/+7
| | | | | | | | | | | | | | | | The clang toolchain might default to fPIE/fPIC, which prevents lld from linking the objects into a binary. Specify -fno-pie -fno-pic as done on GCC to fix linking. Test: Building the Universal Payload using the command 'python UefiPayloadPkg/UniversalPayloadBuild.py -a IA32' actually works. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4356
generated by cgit (git 2.34.1) at 2025-02-23 12:14:52 +0000