summaryrefslogtreecommitdiffstats
path: root/BaseTools/Conf/tools_def.template
Commit message (Collapse)AuthorAgeFilesLines
...
* BaseTools/tools_def.template: fix up LF-only line terminatorLaszlo Ersek2019-01-081-1/+1
| | | | | | | | | | | | | | | "tools_def.template" should only use CRLF line terminators, at this time. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Fixes: 88e8498f8a72cff1f7af6852ec8166772913399e Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1377 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/Conf/tools_def.template: drop ARM/AARCH support from GCC46/GCC47Ard Biesheuvel2019-01-081-129/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | This drops ARM and AARCH64 support from the GCC46 and GCC47 toolchain definitions, which are on the list to be removed, along with VS2003, VS2005, VS2008, VS2010, DDK3790, UNIXGCC, GCC44, GCC45, ELFGCC, CYGGCC, ICC, ICC11 and MYTOOLS. Since GCC46 and GCC47 are the only ones on that list that support ARM and/or AARCH64, let's give Liming a hand and cover the ARM side of things first, so that everything that remains to be removed is x86 only. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1377 Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Liming Gao <liming.gao@intel.com> [lersek@redhat.com: add bugzilla reference and CCs] Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* BaseTools/tools_def ARM: use softfloat target for CLANG3xArd Biesheuvel2018-12-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 'arm-linux-gnueabihf' target triplet we use for CLANG35 and CLANG38 specifies a hardfloat target, and so the binaries that are emitted are annotated as using VFP registers for passing floating point arguments, even though no VFP is used anywhere in the code. This works fine as long as we don't try to link against code that uses software floating point, but combining object files with different floating point calling conventions is not permitted. So switch to the softfloat arm-linux-gnueabi triplet instead. This affects both the name Clang uses when invoking the linker, and the arguments it passes to it, and we are mostly interested in the latter (since any version of GNU ld.bfd will do the right thing as long as it targets EABI ARM) For native builds, this change has no effect, since the unprefixed system linker will take priority, and so Clang will pass the right arguments to whichever linker happens to be the system linker. For cross builds, the fact that Clang composes the name of the linker by prefixing '-ld' with the target triplet implies that users will have to switch to a version of binutils that targets arm-linux-gnueabi rather than arm-linux-gnueabihf. Note that the GCCx toolchain targets can use either when building for ARM so this does not create a need to install two versions of the ARM cross toolchain. Also, note that all ARM toolchains in the GCC family are already documented as requiring a toolchain that targets arm-linux-gnueabi and not arm-linux-gnueabihf. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* BaseTools/tools_def ARM: emit PIC veneersArd Biesheuvel2018-12-191-1/+1
| | | | | | | | | | | | | | | | | The ARM linker may emit veneers, i.e., trampolines, when ordinary direct relative branches cannot be used, e.g., for Thumb interworking or branch targets that are out of range. Usually, such veneers carry an absolute reference to the branch target, which is problematic for us, since these absolute references are not covered by annotations that are visible to GenFw in the PE/COFF conversion, and so these absolute references are not fixed up by the PE/COFF loader at runtime. So switch to all ARM GNU ld toolchains to position independent veneers. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* BaseTools/tools_def ARM CLANG35: work around -mno-movt option name changeArd Biesheuvel2018-12-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PE/COFF only has a very limited id space for runtime relocations, and so it defines only a single relocation for movw/movt instruction pairs, which can be combined to load a 32-bit symbol reference into a register. For this to work as expected, these instructions must always appear in the same order and adjacently, and this is something few compilers take into account, unless they target PE/COFF explicitly (and this is not the case for our ELF based toolchains) For Clang 3.6 and later, we can pass the -mno-movt option to suppress movw/movt pairs entirely, which works around the issue. Unfortunately, for Clang 3.5, the option is called differently (-mllvm -arm-use-movt=0) and mutually incompatible between 3.5 and 3.6. Since it is desirable for the CLANG35 toolchain to be usable on newer versions of Clang as well (given that it is the only non-LTO alternative to CLANG38), let's work around this issue in a way that permits versions 3.5 and newer of Clang to be used with the CLANG35 profile. So pass the -mkernel flag instead (and add -Qunused-argument so Clang does not complain about the -mno-unaligned-access in ARM_CC_XIPFLAGS). This also inhibits movw/movt generation, along with some other changes (e.g., long calls) which do affect code generation but not in an undesirable manner. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/tools_def AARCH64 RELEASE: move GCC49/GGC5 to 4 KB alignmentArd Biesheuvel2018-12-111-12/+14
| | | | | | | | | | | | | | | Since 4 KB section alignment is required when mapping PE/COFF images with strict permissions, update the default section alignment when using GCC49 and GCC5 in RELEASE mode. Note that XIP modules such as SEC, PEIMs or PEI core are not affected by this change, since the override to 32 byte aligment remains in effect. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools tools_def.template: Add GCC link script option in ASLDLINK_FLAGSLiming Gao2018-11-021-1/+1
| | | | | | | | | | | GCC link script is used to discard the unused section data from ELF image. ASLDLINK_FLAGS requires it to remove the unnecessary section data, then GenFw can be used to retrieve the correct data section from ELF image. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* BaseTools Conf: Update tools_def and build_rule to remove IPF settingLiming Gao2018-07-051-773/+0
| | | | | | | Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* BaseTools tools_def.template: Ignore link warning 4281 for VS2017Liming Gao2018-06-251-3/+3
| | | | | | | | | | | | VS2017 reports warning LNK4281: undesirable base address 0x0 for x64 image; set base address above 4GB for best ASLR optimization. edk2 build always sets baes address to zero as default. So, ignore this link warning. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Pete Batard <pete@akeo.ie>
* BaseTools/tools_def CLANG35: add NOOPT build targetArd Biesheuvel2018-06-181-2/+4
| | | | | | | | | | | Create the missing NOOPT target for CLANG35 (which is ARM and AARCH64 only), and align it with the other toolchains: NOOPT has optimizations disabled entirely (for source level debugging), and DEBUG is changed from -O0 to -O1, as is the case for CLANG38 as well. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* BaseTools/tools_def IA32: drop -no-pie linker option for GCC49Ard Biesheuvel2018-06-181-4/+4
| | | | | | | | | | | | | | | | As reported by Liming, GCC 4.9.2 does not support the -no-pie linker option that we added to the GCC49 and GCC5 toolchain profiles in commit c25d3905523a ("BaseTools/tools_def IA32: disable PIE code generation explicitly") to work around issues with recent distro toolchains that enable PIE code generation by default. So rollback the changes for GCC49 but preserve them for GCC5 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/tools_def IA32: disable PIE code generation explicitlyArd Biesheuvel2018-06-121-5/+5
| | | | | | | | | | | | | | | | | As a security measure, some distros now build their GCC toolchains with PIE code generation enabled by default, because it is a prerequisite for ASLR to be enabled when running the executable. This typically results in slightly larger code, but it also generates ELF relocations that our tooling cannot deal with, so let's disable it explicitly when using GCC49 or later for IA32. (Note that this does not apply to X64: it uses PIE code deliberately in some cases, and our tooling does deal with the resuling relocations) Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/tools_def: add "-fno-unwind-tables" to GCC_AARCH64_CC_FLAGSLaszlo Ersek2018-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ElfConvert routines in GenFw don't handle the ".eh_frame" ELF section emitted by gcc. For this reason, Leif disabled the generation of that section for AARCH64 with "-fno-asynchronous-unwind-tables" in commit 28e80befa4fe [1], and Ard did the same for IA32 and X64 in commit 26ecc55c027d [2]. (The CLANG38 toolchain received the same flag at its inception, in commit 6f756db5ea05 [3].) However, ".eh_frame" is back now; in upstream gcc commit 9cbee213b579 [4] (part of tag "gcc-8_1_0-release"), both "-fasynchronous-unwind-tables" and "-funwind-tables" were made the default for AARCH64. (The patch author described the effects on the gcc mailing list [5].) We have to counter the latter flag with "-fno-unwind-tables", otherwise GenFw chokes on ".eh_frame" again (triggered for example on Fedora 28). "-f[no-]unwind-tables" goes back to at least gcc-4.4 [6], so it's safe to add to GCC_AARCH64_CC_FLAGS. [1] https://github.com/tianocore/edk2/commit/28e80befa4fe [2] https://github.com/tianocore/edk2/commit/26ecc55c027d [3] https://github.com/tianocore/edk2/commit/6f756db5ea05 [4] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9cbee213b579 [5] http://mid.mail-archive.com/7b28c03a-c032-6cec-c127-1c12cbe98eeb@foss.arm.com [6] https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Code-Gen-Options.html Cc: "Danilo C. L. de Paula" <ddepaula@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Cole Robinson <crobinso@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reported-by: "Danilo C. L. de Paula" <ddepaula@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools: Separate HOST and PREFIX env for GCC tool chainLiming Gao2018-05-211-7/+8
| | | | | | | | | | | | | | The crossing GCC compiler may use the different path for make and gcc tool. So, GCC_HOST_BIN is introduced for make path. GCC5_BIN is still kept for gcc path. User needs to set GCC_HOST_BIN besides set GCC5_BIN env if the default make is not used. Normally, make is in the default system path. GCC_HOST_BIN is not required to be set. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com>
* BaseTools/Conf: Add /Gw optimisation option for VS2017 IA32 and X64Pete Batard2018-05-071-4/+4
| | | | | | | | | This option, which is used in VS2015 and earlier toolchains, was missing for VS2017. Applying it greatly reduces the size of generated binaries. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Pete Batard <pete@akeo.ie> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/Conf: Add VS2017/ARM64 supportPete Batard2018-03-191-2/+30
| | | | | | | | | | Build options for ARM64 are the same as for ARM, except for /BASE:0 which is removed from DLINK flags to avoid LNK1355 error: invalid base address 0x0; ARM64 image cannot have base address below 4GB Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Pete Batard <pete@akeo.ie> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/tools_def: use separate PP definition for DTCArd Biesheuvel2018-02-281-7/+3
| | | | | | | | | | | | | | Clang's preprocessor behaves differently from GCC's, and produces intermediate device tree source that still contains #pragma pack() and other directives that the device tree compiler chokes on. For assembling device tree sources, it matters very little which preprocessor is being used, so let's just use GNU CPP explicitly. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/Conf: Add VS2017/ARM supportPete Batard2018-02-071-0/+31
| | | | | | | | | We duplicate the Assembly-Code-File section from build_rule.template because --convert-hex cannot be used with the MSFT ARM assembler. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Pete Batard <pete@akeo.ie> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/Conf: disable DTC legacy phandle formatArd Biesheuvel2018-02-061-0/+1
| | | | | | | | | | | | | | | | | By default, the device tree compiler emits phandle properties twice: once called 'phandle' and again called 'linux,phandle'. Given that Linux was updated in early 2010 [0] to accept the former (which is what is specified in the ePAPR and device tree specifications), there is no point in emitting both when compiling device trees for UEFI platforms. [0] 04b954a673dd02f585a2769c4945a43880faa989 "of/flattree: Make the kernel accept ePAPR style phandle information" Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/tools_def CLANG3x: ignore unknown warning optionsArd Biesheuvel2018-01-221-3/+3
| | | | | | | | | | | | | | | Ironically, disabling warnings in the OpensslLib library build is causing breakage when using the CLANG35 toolchain to build for ARM: error: unknown warning option '-Werror=maybe-uninitialized'; did you mean '-Werror=uninitialized'? [-Werror,-Wunknown-warning-option] So let's add -Wno-unknown-warning-option to the list of warnings to ignore when using Clang 3.5, and move the same option from the x86 specific list to the shared list for Clang 3.8. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools: Use nasm as the preferred assembly source files for XCODE5 toolLiming Gao2018-01-161-1/+0
| | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=850 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* BaseTools: Disable -Wno-unused-const-variable in XCODE5 RELEASE targetLiming Gao2018-01-161-3/+3
| | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Andrew Fish <afish@apple.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* BaseTools: Disable warning varargs in XCODE5 align to CLANG38Liming Gao2018-01-161-6/+6
| | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=741 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* BaseTool/tools_def GCC5: enable optimization for ARM/AARCH64 DEBUG buildsArd Biesheuvel2017-12-081-4/+4
| | | | | | | | | | | | | | | | | | | | | Enable optimization for DEBUG builds, to make it more usable in terms of performance, and to give more coverage to the LTO builds. Also, some diagnostics are only enabled when optimization is enabled. NOOPT builds can now also be created, which will retain the behavior DEBUG builds had previously. Note that this aligns ARM and AARCH64 with the x86 architectures, which already use optimization for DEBUG builds. In order to preserve existing behavior for users of older toolchains, keep GCC49 and older as-is. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/tools_def CLANG38: add -Wno-unused-const-variableArd Biesheuvel2017-12-081-1/+1
| | | | | | | | | | | | | | | | | | Commit 8b6366f87584 ("BaseTools/GCC: set -Wno-unused-const-variable on RELEASE builds") suppresses warnings about unused constant variables in RELEASE builds when building with GCC, given that they break the build under our warnings-as-errors policy. Do the same for CLANG38. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=790 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Shi Steven <steven.shi@intel.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/tools_def: add CLANG38 LTO versions for AARCH64 and ARMArd Biesheuvel2017-12-081-3/+95
| | | | | | | | | | | | | | | | | | | | Extend the CLANG38 toolchain definition so it can be used for ARM and AARCH64 as well. Note that this requires llvm-ar and the LLVMgold.so linker plugin. In preparation of doing the same for GCC5, this toolchain version also departs from the custom of using -O0 for DEBUG builds, which makes them needlessly slow. Instead, let's add a NOOPT flavor as well, and enable optimization for DEBUG like the other architectures do. (Note that this will require some trivial changes to the platform description files) Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools: Add VS2017 tool chain in BaseTools tools_def.templateLiming Gao2017-11-291-0/+126
| | | | | | | | | | VS2017 tool chain enables /WHOLEARCHIVE linker option Split host-related and arch-related elements Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Signed-off-by: Pete Batard <pete@akeo.ie> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* BaseTools/tools_def AARCH64 ARM: suppres PIE sections via linker scriptArd Biesheuvel2017-11-231-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | Recent distro builds of GCC 6 enable PIE linking by default, and allow the previous behavior to be restored by passing the -no-pie command line argument. Support for this was implemented by commits 1894a7c64c0a and 3380a591232d but unfortunately, it turns out that GCC 5 does not support this command line argument, and exits with an error. To avoid the need for yet another toolchain tag, to distinguish between GCC 5 and GCC 6, let's use our GCC linker scripts when building objects from .aslc files. This will ensure that the extra sections that are added by the PIE linker are discarded from the ELF binary, and so they will not corrupt the resulting .acpi file. This reverts 1894a7c64c0a BaseTools/tools_def AARCH64 ARM: disable PIE linking 3380a591232d BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sources Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Marcin Wojtas <mw@semihalf.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/tools_def AARCH64 ARM: disable PIE linking for .aslc sourcesArd Biesheuvel2017-11-011-2/+2
| | | | | | | | | | | | | | Commit 1894a7c64c0a ("BaseTools/tools_def AARCH64 ARM: disable PIE linking") works around an issue that was caught due to the fact that PIE linking produces broken .acpi files. However, v2 of that fix inadvertently only applied the workaround to the normal linker command line, and not to the ASLD one, so the issue still persists. So add the missing -no-pie options for ASLD on ARM and AARCH64. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/tools_def: suppress GCC predefined macros in DTB compilationArd Biesheuvel2017-10-271-1/+1
| | | | | | | | | | | | | | | | | | | The standard GCC preprocessor we use to preprocess device tree source files has a whole bunch of macros predefined, among which #define __linux 1 #define __linux__ 1 #define __gnu_linux__ 1 #define linux 1 This causes a property like 'linux,code' to be converted into '1,code' which is obviously wrong. So let's get rid of all the predefined macros by passing -undef to the preprocessor command line. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* BaseTools/tools_def AARCH64 ARM: disable PIE linkingArd Biesheuvel2017-10-271-2/+2
| | | | | | | | | | | Some prebuilt GCC toolchains targeting aarch64 (e.g., the Debian Stretch one) will default to building PIE executables. This has been observed to corrupt ACPI tables built from .aslc sources, so disable PIE linking altogether when using the GCC toolchain to build for AARCH64 or ARM. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/tools_def AARCH64: enable frame pointers for RELEASE buildsArd Biesheuvel2017-09-191-5/+5
| | | | | | | | | | | | | | | | | | | | Commit 8f0b62a5dac0 ("BaseTools/tools_def AARCH64: enable frame pointers for DEBUG builds") removed the -fomit-frame-pointer switch from the CFLAGS definitions that are shared between AARCH64 DEBUG and RELEASE builds, and moved it to the RELEASE specific ones, so that DEBUG builds can produce a backtrace when a crash occurs. This is actually a useful thing to have for RELEASE builds as well. AArch64 has 30 general purpose registers, and so the performance hit of having a frame pointer is unlikely to be noticeable, nor are the additional 8 bytes of stack space likely to present a problem. So remove -fomit-frame-pointer altogether this time. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/GCC: set -Wno-unused-const-variable on RELEASE buildsThomas Lamprecht2017-09-081-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TianoCore BZ#700 [1] Set the '-Wno-unused-const-variables' in RELEASE builds with the GGC49 and GCC5 toolchain. This fixes the RELEASE build of OVMF with GCC in version 6 or newer. GCC 6 added the '-Wunused-const-variable' warning, which gets activated by '-Wunused-variable' and has the following behavior: "Warn whenever a constant static variable is unused aside from its declaration" [2] Commit 2ad6ba80a1bd58382bde6b994070f7c01d2fb48d introduced a case where exactly this happens on a RELEASE build. All uses of the static const variable are located in debug code only, which gets thrown out by the compiler on RELEASE builds and thus triggers the unused-const-variable warning. There is currently no GCC 6 toolchain target defined and doing so would add a lot of boilerplate code. Instead, use the fact that GCC ignores unknown '-Wno-*' options: "[...] if the -Wno- form is used [...] no diagnostic is produced for -Wno-unknown-warning unless other diagnostics are being produced" This behavior is available in GCC 4.9 [3] (and also earlier, for that matter), so add the flag to the GCC49 and GCC5 toolchain, even if both GCC versions do not supports it. GCC49 doesn't enables LTO whereas GCC5 does. As GCC 6.0 through 6.2 had bugs relating to LTO there can be desire to use the GCC49 target even if compiling with GCC 6, see 432f1d83f77a. Orient the changes on 20d00edf21d2 which moved the '-Wno-unused-but-set-variable' flag to RELEASE builds only, as there it ensure that it does not gets raised if the only usage of a variable is in (then collapsed) debug code. [1] https://bugzilla.tianocore.org/show_bug.cgi?id=700 [2] https://gcc.gnu.org/onlinedocs/gcc-6.4.0/gcc/Warning-Options.html#index-Wunused-const-variable [3] https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Warning-Options.html Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com> [lersek@redhat.com: fix typo in subject]
* BaseTools/Gcc ARM AARCH64: add support for building device tree binariesArd Biesheuvel2017-08-311-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While modern AARCH64 server systems use ACPI for describing the platform topology to the OS, ARM systems and AARCH64 outside of the server space mostly use device tree binaries, which are compiled from device tree source files using the device tree compiler. Currently, such source files and binaries may be kept in the EDK2 platform trees, but are not integrated with the build, which means they need to be kept in sync and recompiled manually, which is cumbersome. So let's wire up BaseTools support for them: add tool definitions for the DTC compiler and preprocessor flags that allow these source files to use FixedPcd expressions and other macros defined by AutoGen.h This way, a device tree binary can be built from source and emitted into a FFS file automatically using something like: DeviceTree.inf: [Defines] INF_VERSION = 0x00010019 BASE_NAME = SomePlatformDeviceTree FILE_GUID = 25462CDA-221F-47DF-AC1D-259CFAA4E326 # gDtPlatformDefaultDtbFileGuid MODULE_TYPE = USER_DEFINED VERSION_STRING = 1.0 [Sources] SomePlatform.dts [Packages] MdePkg/MdePkg.dec SomePlatform.fdf: INF RuleOverride = DTB xxx/yyy/DeviceTree.inf [Rule.Common.USER_DEFINED.DTB] FILE FREEFORM = $(NAMED_GUID) { RAW BIN |.dtb } where it can be picked at runtime by the DTB loader that may refer to it using gDtPlatformDefaultDtbFileGuid. Note that this is very similar to how ACPI tables may be emitted into a FFS file with a known GUID and picked up by AcpiTableDxe at runtime. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools: Enable --whole-archive in GCC tool chain as the default optionLiming Gao2017-08-311-2/+2
| | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=581 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* BaseTools/Conf: Support LLVM39 and LLVM40 in CLANG38 toolchainShi, Steven2017-08-291-2/+3
| | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=676 Add LLVM39 and LLVM40 support in CLANG38 toolchain Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Steven Shi <steven.shi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools: Support /WHOLEARCHIVE option in VS2015 tool chainLiming Gao2017-08-291-1/+5
| | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=582 Don't enable this option in the default setting, because it may cause VS2015 linker crash. Platform can enable this option in PlatformPkg.dsc like below: [BuildOptions] *_*_*_DLINK2_FLAGS = /WHOLEARCHIVE Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* BaseTools: Update tools_def to remove /Gw option in VS NOOPT targetLiming Gao2017-08-251-16/+16
| | | | | | | | To remove /Gw option is to disable size optimization. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
* BaseTools: Add the missing -pie link option in GCC tool chainLiming Gao2017-08-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=671 GCC tool chain uses -fpie in CC_FLAGS. So, add -pie in DLINK_FLAGS. More discussion in https://lists.01.org/pipermail/edk2-devel/2017-August/013508.html 3.13 Options for Linking ======================== '-pie' Produce a position independent executable on targets that support it. For predictable results, you must also specify the same set of options used for compilation ('-fpie', '-fPIE', or model suboptions) when you specify this linker option. 3.18 Options for Code Generation Conventions ============================================ '-fpie' '-fPIE' These options are similar to '-fpic' and '-fPIC', but generated position independent code can be only linked into executables. Usually these options are used when '-pie' GCC option is used during linking. '-fpie' and '-fPIE' both define the macros '__pie__' and '__PIE__'. The macros have the value 1 for '-fpie' and 2 for '-fPIE'. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* BaseTools/Conf: apply nasmb, asm16 build rule orderChris Ruffin2017-08-071-1/+1
| | | | | | | | | Prioritize nasmb rule over asm16 where both source types are specified. Change-Id: I33ec348dab66b313ddb05cb15f2d8407a648c320 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Chris Ruffin <chris.ruffin@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/tools_def AARCH64: avoid SIMD registers in XIP codeArd Biesheuvel2017-07-141-1/+1
| | | | | | | | | | | | | | XIP code may execute with the MMU off, in which case all memory accesses should be strictly aligned to their size. Some versions of GCC violate this restriction even when -mstrict-align is passed, when performing loads and stores that involve SIMD registers. This is clearly a bug in the compiler, but we can easily work around it by avoiding SIMD registers altogether when building code that may execute in such a context. So add -mgeneral-regs-only to the AARCH64 XIP CC flags. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* BaseTools/tools_def AARCH64: mark register x18 as reservedArd Biesheuvel2017-07-141-1/+1
| | | | | | | | | | | | | | | The AArch64 ABI classifies register x18 as a platform register, which means it should not be used unless the code is guaranteed to run on a platform that doesn't use it in such a capacity. GCC does not honour this requirement by default, and so we need to tell it not to touch it explicitly, by passing the -ffixed-x18 command line option. Link: https://bugzilla.tianocore.org/show_bug.cgi?id=625 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* BaseTools: Update tools_def.template to remove old XCLANG and XCODE32Liming Gao2017-07-051-176/+0
| | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=562 https://bugzilla.tianocore.org/show_bug.cgi?id=563 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Andrew Fish <afish@apple.com>
* BaseTools: add /Gw to CC_FLAGS for VS2013 and higher tool chain tagsYonghong Zhu2017-06-231-48/+48
| | | | | | | | | | | | The /Gw flag does a better job at size optimization than use of the GLOBAL_REMOVE_IF_UNREFERENCED macro that is currently used for VS20xx tool chains to remove unreferenced global variables. This patch add /Gw to CC_FLAGS for VS2013 and higher tool chain tags. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools/tools_def: AARCH64: disable LTO type mismatch warningsArd Biesheuvel2017-06-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On AARCH64, any code that may execute with the MMU off needs to be built with -mstrict-align, given that unaligned accesses are not allowed unless the MMU is enabled. This does not only affect SEC and PEI modules, but also static libraries of the BASE type, which may be linked into such modules, as well as into modules of other types. As it turns out, the presence of -mstrict-align is reflected in the internal representations of the types defined in those libraries. When -fstrict-aliasing is passed to GCC, it assumes that pointers to objects of different types cannot refer to the same memory location, and attempts to exploit this fact when optimizing the code. Since such assumptions are only valid under very strict conditions which are not guaranteed to be met in EDK2, we disable this optimization by passing -fno-strict-aliasing by default. [*] When LTO is in effect, this applies equally to the code generation that may occur at link time, which is why the linker warns about unexpected differences in type definitions between the intermediate representations that are present in the object files being linked. This may result in warnings such as the one below, even if -fno-strict-aliasing is used: MdePkg/Include/Library/BaseLib.h:1712:1: warning: type of 'StrToGuid' does not match original declaration [-Wlto-type-mismatch] StrToGuid ( ^ MdePkg/Library/BaseLib/SafeString.c:1506:1: note: 'StrToGuid' was previously declared here StrToGuid ( ^ MdePkg/Library/BaseLib/SafeString.c:1506:1: note: code may be misoptimized unless -fno-strict-aliasing is used This warning is inadvertently triggered when linking BASE libraries built with -mstrict-align into modules of types other than SEC or PEI, since the types are subtly different, even though the use of code that maintains strict alignment in a module that does not care about this is unlikely to cause problems. And even if it did, it would still only affect code built with -fstrict-aliasing enabled, which we disable unconditionally. So let's just silence the warning by passing -Wno-lto-type-mismatch. [*] Leif adds: "-fstrict-aliasing is GCC default, because it is a restriction in the C language. Because it's a bit non-obvious, things can go hilariously wrong in very non-obvious ways, and the potential optimization gains are unlikely to be generally relevant, -fno-strict-aliasing is a sensible thing to always have set (like we do)." Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
* BaseTools/tools_def GCC: ARM/AARCH64: drop -save-temps from command lineArd Biesheuvel2017-06-221-3/+3
| | | | | | | | | | | | | For historical reasons, GCC builds for ARM and AARCH64 pass the -save-temps command line option to GCC, which instructs the compiler to preserve intermediate files, i.e., preprocessor output and generated assembler. Given that this clutters up the Build directory, and slows down the build, let's remove it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools/GCC ARM/AARCH64: Force disable PIEdann frazier2017-06-011-2/+2
| | | | | | | | | | | | | | | After Debian's toolchain switched to PIE by default, our edk2 builds began to fail to build (GCC49 w/ gcc 6.3). This patch fixes the build by forcing off PIE for both ARM and AARCH64 builds. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: dann frazier <dannf@debian.org> Add -fno-pic as well for ARM. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
* BaseTools: Clean up tools_def.template for XCODE5Michael Kinney2017-05-191-26/+28
| | | | | | | | | | | Reorganize the statements for XCODE5 to match other tool chains and remove dependency on XCLANG and XCODE32 Cc: Andrew Fish <afish@apple.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Andrew Fish <afish@apple.com>
* BaseTools: Add -D NO_MSABI_VARGS to X64 XCODE5 CC_FLAGSMichael Kinney2017-05-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=561 Update BaseTools/Conf/tools_def.template to add the define -D NO_MSABI_VAARGS To CC_FLAGS for X64 XCODE5 builds. The llvm/clang compiler used in XCODE5 builds supports the _ms_ versions of the vararg builtins, but the compiler generates build errors. The recommendation from the XCODE5 experts is to never use the _ms_ version of the vararg builtins. The define NO_MSABI_VARARGS is already supported in MdePkg/Include/Base.h and forces the use the standard vararg builtins. Cc: Andrew Fish <afish@apple.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Andrew Fish <afish@apple.com>
* BaseTools: Add option in CLANG38 to disable warning unknown-warning-optionLiming Gao2017-04-111-1/+1
| | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=466 Cc: Yonghong Zhu <yonghong.zhu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-17 18:52:45 +0000