summaryrefslogtreecommitdiff
path: root/BaseTools/Conf/tools_def.template
AgeCommit message (Collapse)Author
2016-07-13BaseTools AARCH64: move DEBUG GCC49 to the small code modelArd Biesheuvel
When building AARCH64 platforms that include a Shell binary built from source, we run into trouble when using the tiny code model for DEBUG builds. The reason is that the Shell binary built in DEBUG mode exceeds the 1 MB range of the ADR instruction, so anything that gets pulled into the final link of the Shell binary either needs to be built with the small or large model, or needs to be sorted in some way to put the ADR references close to their targets. Since code size is not a big concern for DEBUG builds anyway, let's move to the small code model for all modules when using DEBUG GCC49. This way, there is no need for workarounds that are specific to UEFI_APPLICATION modules in general, or the Shell application in particular. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> (cherry picked from commit f37d891c1b870b294964adf65f619a661700fcab)
2016-07-13BaseTools/GCC: set -Wno-unused-but-set-variables only on RELEASE buildsArd Biesheuvel
This aligns the GCC definitions for 4.6 and up to align with the ARM and AARCH64 definitions, which is to ignore unused but set variables only on RELEASE builds. This allows us to find instances of unused variables that are left behind after refactoring. It also allows us to find bad new code, which, due to the EDK2 coding style which disallows initialized automatic variables, may contain such variables without having been noticed by other toolchains. (Slightly edited) observation from Jordan Justen <jordan.l.justen@intel.com>: RELEASE builds must keep the flag because debug code (such as assertions) may collapse to nothing -- e.g. if a platform defines MDEPKG_NDEBUG for RELEASE -- and therefore trigger the warning. 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: Laszlo Ersek <lersek@redhat.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> [lersek@redhat.com: incorporate commit message update from Jordan] Signed-off-by: Laszlo Ersek <lersek@redhat.com> (cherry picked from commit 20d00edf21d2f2144921622891d8b59a1553cd83)
2016-03-02BaseTools/tools_def.txt: Add -march=i586 for IA32 GCC targetsMichael Kinney
Newer GCC compilers use a default of march higher than i586 for -m32 (IA32 configuration) and this is causing generation of instructions that are not compatible with all IA32 targets. Specically Galileo platform support in the QuarkPlatformPkg does not boot if GCC48 or higher is used. This is similar to the following checkin that was done to address this same issue for VS2012 and higher tool chains: SHA-1: 71028ba2c4c398d70475504e671d048d9003d90f Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Leroy Leahy <leroy.p.leahy@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> (cherry picked from commit c261c27dcee4603b9628d68639e7dccc4253af7e)
2016-02-24BaseTools AARCH64: build XIP modules with strict alignmentArd Biesheuvel
GCC for AARCH64 recognizes byte swapping load and store sequences and may replace them with wider loads or stores combined with rev instructions. In some cases (i.e., with GCC version 5 and later) this may result in unaligned accesses, which are not allowed before we turn the MMU on. So build any modules or static libraries that may execute with the MMU off with -mstrict-align. Other modules don't need this switch, so we can remove it from the CLANG35/AARCH64 common CC flags. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19638 6f19259b-4bc3-4df7-8a09-765794883524 (cherry picked from commit d764d59849b782c11424f27c2148ecb057533a76)
2016-02-24BaseTools CLANG35: use -target in PP flags as wellArd Biesheuvel
The Clang preprocessor may rely on builtin defines that are target dependent, so we should add the -target argument also when invoking the preprocessor directly. 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> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19584 6f19259b-4bc3-4df7-8a09-765794883524 (cherry picked from commit c2a892d7c8a78143006bb7fdc95fb18f7e2fc685)
2016-02-24BaseTools CLANG35: use linux-gnu target triplets explicitlyArd Biesheuvel
Since we are combining Clang with the GNU linker, make that explicit in the target triplet. This affects certain builtin defines and other compiler behavior that may be unspecified otherwise. 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> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19583 6f19259b-4bc3-4df7-8a09-765794883524 (cherry picked from commit d4dcd5542a88eeee5a268284a4dfe026918f1720)
2015-12-18BaseTools ARM: add CLANG35 supportArd Biesheuvel
This extends the existing CLANG35 toolchain definition with support for building for the ARM architecture. In order to be able to reuse the existing ARM GCC definitions as much as possible, the following changes have been made to the existing ARM GCC support: - the -mapcs option has been removed; it is a no-op under Thumb (our default) and we use AAPCS (-mabi=aapcs) anyway - the -mword-relocations option has been moved from GCC_ARM_CC_FLAGS to the GCC4x specific option: CLANG does not support it, and uses '-mllvm -marm-use-movt=0' instead. (Sync patch r19284 from main trunk.) 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> git-svn-id: https://svn.code.sf.net/p/edk2/code/branches/UDK2015@19386 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-18BaseTools RVCT: use scatter file to enforce minimum section alignmentArd Biesheuvel
Up until SVN r18540, GenFw created invalid PE/COFF binaries for the ARM architecture, by allowing PE/COFF .data sections to appear at offsets that were not aligned to the global PE/COFF section alignment. The reason for this was that the relocation metadata emitted by RVCT's armlink only contains dynamic absolute relocations, so it is impossible to recalculate relative relocations between .text and .data, and so the relative offset between the two needs to be preserved. Since r18540, we do align .data to the PE/COFF section alignment, resulting in potentially corrupt PE/COFF binaries unless .data happens to appear at a 32-byte aligned offset. So let's introduce a RVCT scatter file that sets this alignment for the ELF .data section (and subsequent .bss section). At the same time, set the start offset to 0x220 bytes (which is the size of our 32-bit PE/COFF header) so that the memory layouts are identical between ELF and PE/COFF. Also add a 4 KB aligned version that can be used to build DXE_RUNTIME_DRIVER modules with runtime memory protection enabled. (Sync patch r19235 from main trunk.) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Eugene Cohen <eugene@hp.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/branches/UDK2015@19382 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-18BaseTools GCC: avoid the use of COMMON symbolsArd Biesheuvel
The default behavior of the GCC compiler is to emit uninitialized globals with external linkage into a COMMON section, where duplicate definitions are merged. This may result in unexpected behavior, since global variables defined under the same name in different C files may not refer to the same logical data item. For instance, the definitions of EFI_EVENT mVirtualAddressChangeEvent that [used to] appear in the following files: CryptoPkg/Library/BaseCryptLib/SysCall/RuntimeMemAllocation.c MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c will be folded into a single instance of the variable when the latter module includes the former library, which can lead to unexpected results. Even if some may argue that there are legal uses for COMMON allocation, the high modularity of EDK2 combined with the low level of awareness of the intracicies surrounding common allocation and the generally poor EDK2 developer discipline regarding the use of the STATIC keyword* make a strong case for disabling it by default, and re-enabling it explicitly for packages that depend on it. So prevent GCC from emitting variables into the COMMON section, by passing -fno-common to the compiler, and discarding the section in the GNU ld linker script. * Any function or variable that is only referenced from the translation unit that defines it could be made STATIC. This does not only prevent issues like the above, it also allows the compiler to generate better code, e.g., drop out of line function definitions after inlining all invocations or perform constant propagation on variables. (Sync patch r19164 from main trunk.) 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: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/branches/UDK2015@19381 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-18BaseTools RVCT: add preprocessor preinclude for AutoGen.hEugene Cohen
Ensure that AutoGen.h is force-included when the RVCT preprocessor is invoked. (Sync patch r19097 from main trunk.) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen <eugene@hp.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/branches/UDK2015@19370 6f19259b-4bc3-4df7-8a09-765794883524
2015-12-04BaseTools: Add VS2015 tool chain in tools_def.templateWang Yu
(Sync patch r19101 from main trunk.) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wang Yu <yu.wang@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/branches/UDK2015@19117 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-16Update BaseTools from main trunk r18767.Jeff Fan
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/branches/UDK2015@18784 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-20BaseTools AARCH64: use tiny code model by defaultArd Biesheuvel
The AARCH64 tiny code model produces more efficient code, since it uses relative symbol references rather than absolute references, i.e., an emitted relative reference refers to the symbol directly rather than a literal containing its 64-bit absolute address. This saves space in the binary, and reduces the number of relocation fixups that need to be applied by the PE/COFF loader. So now that we support relative relocations in GenFw, move to the tiny code model by default. Note that the large model can still be selected by individual modules by adding -mcmodel=large to the appropriate CC_FLAGS. Contributed-under: TianoCore Contribution Agreement 1.0 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> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18242 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-18BaseTools: Add /arch:IA32 option in VS2012 and VS2013Liming Gao
VS2012 and VS2013 turn on optimizations by default that generate the use of CMOV instruction. This is a change from previous version VS2008. This means when you build with VS2012 or VS2013, it will generate UD exceptions on Quark. To resolve it, add /arch:IA32 options to not use enhanced instructions. https://msdn.microsoft.com/en-us/library/7t5yh4fd(v=vs.140).aspx Update the default options of VS2012 & VS2013 tool chain IA32 arch in BaseTools\Conf\tools_def.template to make sure the generated Quark compatibility driver. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18230 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-17BaseTools GCC: prevent unaligned memory accesses on ARM GCC 4.6Ard Biesheuvel
In GCC 4.7, a feature was added to the ARM backend that allows unaligned loads and stores to be emitted. Since it is enabled by default on ARMv6 and later CPUs, and since such code is not suitable in our case (i.e., bare metal code), we must disable it by passing the -mno-unaligned-access option if we are using GCC 4.7 or later. However, this particular feature and its enabling by default have been backported to version 4.6 by Linaro. Since the Linaro toolchains are widely used for ARM development, and also shipped by distros such as Ubuntu, we should disable the feature on version 4.6 as well. Unfortunately, since the upstream version does not support the feature, it also does not understand the -mno-unaligned-access option. Since GCC sets the builtin #define __ARM_FEATURE_UNALIGNED to 1 when -munaligned-access is in effect, we can force the build to fail in this case by passing -D__ARM_FEATURE_UNALIGNED=0 on the GCC command line. This will produce the following error message: <command-line>:0:0: error: "__ARM_FEATURE_UNALIGNED" redefined [-Werror] <built-in>:0:0: note: this is the location of the previous definition and terminate the build. This patch may cause some existing builds to fail, but they will be builds that were previously at risk of unexpected runtime exceptions. Those builds can also easily be switched to the GCC47 profile instead, generating safe binaries. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18228 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-13BaseTools IA32/X64: prevent .eh_frame sections from being generatedArd Biesheuvel
After the recent GNU linker script changes, the following warning is emitted many times during the OVMF build: BFD: <...>: warning: Empty loadable segment detected, is this intentional ? This is caused by the fact that, now that the section layout has changed somewhat, the .eh_frame section is assigned an ELF segment of its own, which ends up with no contents at all after we strip the .eh_frame section from the output. (Note that the program headers that contain the segment information are completely irrelevant to us since the PE/COFF conversion does not rely on them.) Since we only retain the .eh_frame data for external debugging, and not for things like stack unwinding or generating backtraces at runtime, we can remedy the situation by passing -fno-asynchronous-unwind-tables on the GCC command line. This option instructs the compiler to emit the unwind data into a debug section called .debug_frame instead of into .eh_frame. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18217 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-12BaseTools: remove ARMGCC and ARMLINUXGCC toolchainsArd Biesheuvel
The ARMGCC and ARMLINUXGCC toolchains are specific to the ARM and AARCH64 architectures, and overlap with the toolchain configuration that is provided by the GCC44 - GCC49 toolchains, which are defined for all architectures. To reduce the maintenance burden, and make it easier to keep these different architectures aligned, remove the ARMGCC and ARMLINUXGCC toolchains entirely. 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> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18212 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-10BaseTools: add CLANG35 toolchain with AARCH64 supportArd Biesheuvel
This adds support for building the AARCH64 platforms using the Clang compiler and assembler combined with the GNU (cross-)linker. The chosen name CLANG35 is based on version 3.5 being the oldest supported version, but no issues are known that should prevent its use with any later version. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18198 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-03BaseTools IA32/X64: Use GccBase.lds instead of gcc*-ld-scriptArd Biesheuvel
These scripts all now have the same contents, so we only need to use GccBase.lds. Therefore we can delete gcc-4K-align-ld-script, gcc4.4-ld-script and gcc4.9-ld-script. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18142 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-03BaseTools AARCH64: move to unified GCC linker scriptArd Biesheuvel
Drop the GCC AARCH64 specific linker script and use the new unified one instead. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18138 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-03BaseTools IA32/X64: get header size and alignment from ld commandlineArd Biesheuvel
Instead of hardcoding the values for the PE/COFF header size and the section alignment, set them on the linker command line. This factors out these values from the various linker scripts, which will allow us to unify them in a subsequent patch. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18134 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-09BaseTools: aarch64: add -fno-asynchronous-unwind-tables to gcc cflagsLeif Lindholm
Some toolchains, at least Fedora GCC, generate inline unwind tables in object files. These confuses GenFw to no end, leading to build failures: GenFw: ERROR 3000: Invalid WriteSections64(): ... unsupported ELF EM_AARCH64 relocation 0x105. GenFw: ERROR 3000: Invalid WriteSections64(): ... unsupported ELF EM_AARCH64 relocation 0x0. I am aware of no current use of these tables, so explicitly disable their generation for aarch64. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Tested-by: Wei Huang <wei@redhat.com> Reviewed-by: Olivier Martin <olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17905 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-06BaseTools: AArch64: use explicit linker scriptsArd Biesheuvel
Instead of relying on the builtin linker script of GNU ld, which may vary based on binutils version (which is not tightly coupled to the GCC version) and linker command line options, introduce a linker script for AArch64 to be used by all GCC/binutils versions. The script is laid out such that two ELF sections .text and .data are created that map onto the PE/COFF with the same names. By aligning .data to the minimum alignment of .text, and by not adding any additional padding -which is what LD's builtin linker script does- the relative offset between .text and .data is retained after the PE/COFF conversion. This should prevent problems with debuggers and other tooling that are ELF based. Also provided is an overlay linker script that increases the alignment of .text and .data to 64 KB. This is intended for DXE_RUNTIME_DRIVER modules, to make them compatible with the newly introduced Properties Table feature. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Olivier Martin <Olivier.Martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17824 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-02Revert tree to r17801Jordan Justen
Revert r17802 "BaseTools: AArch64: use explicit linker scripts" Revert r17803 "ArmVirtPkg: build runtime drivers with 64 KB section alignment" Revert r17804 "IntelFrameworkModulePkg: AcpiS3SaveDxe: prepare for End-of-Dxe callback" Revert r17805 "IntelFrameworkModulePkg: AcpiS3SaveDxe: call S3Ready() at End-of-Dxe" Revert r17806 "OvmfPkg: AcpiS3SaveDxe: prepare for End-of-Dxe callback" Requested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17807 6f19259b-4bc3-4df7-8a09-765794883524
2015-07-02BaseTools: AArch64: use explicit linker scriptsArd Biesheuvel
Instead of relying on the builtin linker script of GNU ld, which may vary based on binutils version (which is not tightly coupled to the GCC version) and linker command line options, introduce a linker script for AArch64 to be used by all GCC/binutils versions. The script is laid out such that two ELF sections .text and .data are created that map onto the PE/COFF with the same names. By aligning .data to the minimum alignment of .text, and by not adding any additional padding -which is what LD's builtin linker script does- the relative offset between .text and .data is retained after the PE/COFF conversion. This should prevent problems with debuggers and other tooling that are ELF based. Also provided is an overlay linker script that increases the alignment of .text and .data to 64 KB. This is intended for DXE_RUNTIME_DRIVER modules, to make them compatible with the newly introduced Properties Table feature. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17802 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-29BaseTools: Updated tool_def to support 4K alignment.Yingke Liu
Replace '/MERGE:.data=.text /MERGE:.rdata=.text' with /MERGE:.rdata=.data Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yingke Liu <yingke.d.liu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17726 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-29BaseTools: Update IASL download link and remove specific version info.Yingke Liu
The version of IASL compiler in the tools_def.template file no longer exists on the acpica.org site. Update download link and remove the specific version info from the tools_def.template file. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yingke Liu <yingke.d.liu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17725 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-01BaseTools/Conf: Don't support upper case nasm extensionsJordan Justen
For *.asm and *.s, there have been cases of *.Asm and *.S files, but since the nasm extensions are new, we don't need to support the upper case extensions. In other words, remove .Nasm and .NASM. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17544 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-26BaseTools: Add default BuildRuleOrder in tools_def.templateYingke Liu
*_*_*_*_BUILDRULEORDER = nasm Nasm NASM asm Asm ASM S s *_XCODE32_*_*_BUILDRULEORDER = S s nasm Nasm NASM *_XCLANG_*_*_BUILDRULEORDER = S s nasm Nasm NASM *_XCODE5_*_*_BUILDRULEORDER = S s nasm Nasm NASM Tool Chain in Mac Os will use S as the first priority. Other tool chains use nasm as the first priority. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yingke Liu <yingke.d.liu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17510 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-23NT32Pkg: Fix build errors from building secure boot with NT32 X64Cinnamon Shia
Root cause: The CryptoPkg\Library\IntrinsicLib needs override MSFT build option to remove /Oi and /GL, but it doesn’t work because of the build option override in Nt32Pkg.dsc. Solution: Remove /X in BaseTools/Conf/tools_def.template Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia <cinnamon.shia@hp.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17069 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-09BaseTools Fix NASM tool version in comments of tools_def.templateLiming Gao
NASM tool version should be 2.07 instead of 2.0.7. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16596 6f19259b-4bc3-4df7-8a09-765794883524
2014-12-02Fix ARM build failure with gcc 4.6.Scott Duplichan
Gcc option -mno-unaligned-access is supported by gcc 4.7 and newer, so it shouldn't be used with gcc 4.6. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Yingke Liu <yingke.d.liu@intel.com> Reviewed-by: Olivier Martin <Olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16464 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-24BaseTools: Extend support for Windows hosted gcc to versions 4.4-4.7.Scott Duplichan
Revision 16400 adds support for Windows hosted gcc versions 4.8 and 4.9. With this change, all of the GCCXX tool chains can be used from Windows. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16418 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-18BaseTools: Modify gcc 4.8 and 4.9 tool chain definition to support building ↵Scott Duplichan
from Windows. Here is a new patch that adds Windows support for both gcc 4.8.x and gcc 4.9.x. This time testing is more thorough: boot testing using Duet for all 4 combinations of IA32/X64 and gcc 4.8.2 and gcc 4.9.1 passes. A Windows hosted gcc 4.8.2 has been added here: http://sourceforge.net/projects/edk2developertoolsforwindows/ The environment variable settings for Windows look like: set UEFI_BUILD_TOOLS=%cd%\tools set NASM_PREFIX=%UEFI_BUILD_TOOLS%\nasm211\ set GCC48_BIN=%UEFI_BUILD_TOOLS%\gcc482-x86\bin\ set GCC48_DLL=%UEFI_BUILD_TOOLS%\gcc482-x86\dll\;%GCC48_BIN% set GCC48_ARM_PREFIX=%UEFI_BUILD_TOOLS%\gcc482-arm\bin\ set GCC48_AARCH64_PREFIX=%UEFI_BUILD_TOOLS%\gcc482-aarch64\bin\ set GCC49_BIN=%UEFI_BUILD_TOOLS%\gcc491-x86\bin\ set GCC49_DLL=%UEFI_BUILD_TOOLS%\gcc491-x86\dll\;%GCC49_BIN% set GCC49_ARM_PREFIX=%UEFI_BUILD_TOOLS%\gcc491-arm\bin\ set GCC49_AARCH64_PREFIX=%UEFI_BUILD_TOOLS%\gcc491-aarch64\bin\ No change is needed for building from Linux. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16400 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-18BaseTools: Correct NASM output file type for UNIXGCC and CYGGCC. Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yingke Liu <yingke.d.liu@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16399 6f19259b-4bc3-4df7-8a09-765794883524
2014-09-25BaseTools: Use '/' as path separator for objcopy --add-gnu-debuglinkNikolai Saoukh
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Nikolai Saoukh <nms@otdel-1.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16172 6f19259b-4bc3-4df7-8a09-765794883524
2014-09-10BaseTools: Fix XCODE5 to work properly with NASMAndrew Fish
The default object type for NASM is raw binary, and this will not link. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Andrew Fish <afish@apple.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16085 6f19259b-4bc3-4df7-8a09-765794883524
2014-09-01BaseTools tools_def: Indicate that NASM 2.07 or later is requiredJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16018 6f19259b-4bc3-4df7-8a09-765794883524
2014-09-01BaseTools build_rule: Add .nasm => .obj build ruleJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16017 6f19259b-4bc3-4df7-8a09-765794883524
2014-09-01BaseTools tools_def: Add NASM_FLAGSJordan Justen
Note: Only tested with the GCC49 toolchain so far. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16016 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-29BaseTools: Add the XCODE5 tools target to supoprt Xcode 5Anderw Fish
Xcode 5 changed the arguments required to supoprt X64 EFIAPI so it is a new target. XCODE5 supports Xcode 5.* and Xcode 6.*, and will probably support future versions of Xcode as well. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anderw Fish <afish@apple.com> Reviewed-by: Gao, Liming <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15979 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-28BaseTools: add support Xcode 5 in the EmulatorPkgAndrew Fish
The XCODE32 target is used to build the x86_64 Mac OS X application for the emulator. The other Xcode targets build the EFIAPI needed for UEFI. This patch removes an obsolete command line argument. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Andrew Fish <afish@apple.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15930 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-20BaseTools: Added support for GCC stack protector for ARM architectureOlivier Martin
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-by: Yingke Liu <yingke.d.liu@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15854 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-18BaseTools: Add rules to build NASM source file into a binaryJordan Justen
v2: * Use EDK II tool name of NASMB rather than NASMBIN * Use EDK II extension of .nasmb rather than .nasmbin v3: * Create listing file * Don't change into source directory * Add ENV(NASM_PREFIX) before nasm for NASM_PATH Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15820 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-14Contributed-under: TianoCore Contribution Agreement 1.0Michael Kinney
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Yingke Liu <yingke.d.liu@intel.com> Add support for RSA 2048 SHA 256 signing and verification encoded in a PI FFS GUIDED Encapsulation Section. The primary use case of this feature is in support of signing and verification of encapsulated FVs for Recovery and Capsule Update, but can potentially be used for signing and verification of any content that can be stored in a PI conformant FFS file. Signing operations are performed from python scripts that wrap OpenSsl command line utilities. Verification operations are performed using the OpenSsl libraries in the CryptoPkg. The guided encapsulation sections uses the UEFI 2.4 Specification defined GUID called EFI_CERT_TYPE_RSA2048_SHA256_GUID. The data layout for the encapsulation section starts with the UEFI 2.4 Specification defined structure called EFI_CERT_BLOCK_RSA_2048_SHA256 followed immediately by the data. The signing tool included in these patches performs encode/decode operations using this data layout. HashType is set to the UEFI 2.4 Specification defined GUID called EFI_HASH_ALGORITHM_SHA256_GUID. MdePkg/Include/Guid/WinCertificate.h ================================= // // WIN_CERTIFICATE_UEFI_GUID.CertType // #define EFI_CERT_TYPE_RSA2048_SHA256_GUID \ {0xa7717414, 0xc616, 0x4977, {0x94, 0x20, 0x84, 0x47, 0x12, 0xa7, 0x35, 0xbf } } /// /// WIN_CERTIFICATE_UEFI_GUID.CertData /// typedef struct { EFI_GUID HashType; UINT8 PublicKey[256]; UINT8 Signature[256]; } EFI_CERT_BLOCK_RSA_2048_SHA256; MdePkg/Include/Protocol/Hash.h ================================= #define EFI_HASH_ALGORITHM_SHA256_GUID \ { \ 0x51aa59de, 0xfdf2, 0x4ea3, {0xbc, 0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 } \ } The verification operations require the use of public key(s). A new PCD called gEfiSecurityPkgTokenSpaceGuid.PcdRsa2048Sha256PublicKeyBuffer is added to the SecurityPkg that supports one or more SHA 256 hashes of the public keys. A SHA 256 hash is performed to minimize the FLASH overhead of storing the public keys. When a verification operation is performed, a SHA 256 hash is performed on EFI_CERT_BLOCK_RSA_2048_SHA256.PublicKey and a check is made to see if that hash matches any of the hashes in the new PCD. It is recommended that this PCD always be configured in the DSC file as storage type of [PcdsDynamixExVpd], so the public keys are stored in a protected read-only region. While working on this feature, I noticed that the CRC32 signing and verification feature was incomplete. It only supported CRC32 based verification in the DXE Phase, so the attached patches also provide support for CRC32 based verification in the PEI Phase. I also noticed that the most common method for incorporating guided section extraction libraries was to directly link them to the DXE Core, which is not very flexible. The attached patches also add a generic section extraction PEIM and a generic section extraction DXE driver that can each be linked against one or more section extraction libraries. This provides a platform developer with the option of providing section extraction services with the DXE Core or providing section extraction services with these generic PEIM/DXE Drivers. Patch Summary ============== 1) BaseTools - Rsa2049Sha256Sign python script that can perform test signing or custom signing of PI FFS file GUIDed sections a. Wrapper for a set of OpenSsl command line utility operations b. OpenSsl command line tool must be installed in location that is in standard OS path or in path specified by OS environment variable called OPENSSL_PATH c. Provides standard EDK II command line arguments for a tool that encodes/decodes guided encapsulation section Rsa2048Sha256Sign - Copyright (c) 2013 - 2014, Intel Corporation. All rights reserved. usage: Rsa2048Sha256Sign -e|-d [options] <input_file> positional arguments: input_file specify the input filename optional arguments: -e encode file -d decode file -o filename, --output filename specify the output filename --private-key PRIVATEKEYFILE specify the private key filename. If not specified, a test signing key is used. -v, --verbose increase output messages -q, --quiet reduce output messages --debug [0-9] set debug level --version display the program version and exit -h, --help display this help text 2) BaseTools - Rsa2049Sha256GenerateKeys python script that can generate new private/public key and PCD value that is SHA 256 hash of public key using OpenSsl command line utilities. a. Wrapper for a set of OpenSsl command line utility operations b. OpenSsl command line tool must be installed in location that is in standard path or in path specified by OS environment variable called OPENSSL_PATH Rsa2048Sha256GenerateKeys - Copyright (c) 2013 - 2014, Intel Corporation. All rights reserved. usage: Rsa2048Sha256GenerateKeys [options] optional arguments: -o [filename [filename ...]], --output [filename [filename ...]] specify the output private key filename in PEM format -i [filename [filename ...]], --input [filename [filename ...]] specify the input private key filename in PEM format --public-key-hash PUBLICKEYHASHFILE specify the public key hash filename that is SHA 256 hash of 2048 bit RSA public key in binary format --public-key-hash-c PUBLICKEYHASHCFILE specify the public key hash filename that is SHA 256 hash of 2048 bit RSA public key in C structure format -v, --verbose increase output messages -q, --quiet reduce output messages --debug [0-9] set debug level --version display the program version and exit -h, --help display this help text 3) BaseTools\Conf\tools_def.template a. Define GUID/Tool to perform RSA 2048 SHA 256 test signing and instructions on how to use alternate private/public key b. GUID is EFI_CERT_TYPE_RSA2048_SHA256_GUID c. Tool is Rsa2049Sha256Sign 4) MdeModulePkg\Library\PeiCrc32GuidedSectionExtractionLib a. Add peer for DxeCrc32GuidedSectionExtractionLib so both PEI and DXE phases can perform basic integrity checks of PEI and DXE components 5) MdeModulePkg\Universal\SectionExtractionPei a. Generic PEIM that can link against one or more NULL section extraction library instances to provided one or more GUIDED Section Extraction PPIs 6) MdeModulePkg\Universal\SectionExtractionDxe a. Generic DXE Driver that can link against one or more NULL section extraction library instances to provide one or more GUIDED Section Extraction Protocols. 7) SecurityPkg\Library\PeiRsa2048Sha256GuidedSectionExtractLib a. NULL library instances that performs PEI phase RSA 2048 SHA 256 signature verification using OpenSsl libraries from CryptoPkg. b. Based on algorithms from SecurityPkg Authenticated Variable services c. Uses public key from gEfiSecurityPkgTokenSpaceGuid.PcdRsa2048Sha256PublicKeyBuffer. 8) SecurityPkg\Library\DxeRsa2048Sha256GuidedSectionExtractLib a. NULL library instances that performs DXE phase RSA 2048 SHA 256 signature verification using OpenSsl libraries from CryptoPkg. b. Based on algorithms from SecurityPkg Authenticated Variable services c. Uses public key from gEfiSecurityPkgTokenSpaceGuid.PcdRsa2048Sha256PublicKeyBuffer. git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15800 6f19259b-4bc3-4df7-8a09-765794883524
2014-08-01CodeModule: BaseTools - tools_def.txt VS2010, VS2010x86, VS2012 and ↵lhauch
VS2012x86 update locations for rc.exe tool This change will point to the correct location of the rc.exe tool. RC.exe is used for building UEFI compliant drivers that must have a UEFI_HII_RESOURCE_SECTION generated as part of the .efi image file. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: lhauch <larry.hauch@intel.com> Reviewed-by: Gao, Liming <liming.gao@intel.com> Reviewed-by: Yingke Liu <yingke.d.liu@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15735 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-31Add VS2013 tool chain in BaseTools\Conf\tools_def.template. Also, two ↵Wang, Yu
issues came up related to vs2013 build and caused the build to fail. Vs2013 issue #1: warning message about uninitialized variables or pointers like this: s:\incbld\ia32\intelframeworkmodulepkg\bus\isa\isabusdxe\isabus.c(395) : warning C4701: potentially uninitialized local variable 'DevicePathData' used s:\incbld\ia32\intelframeworkmodulepkg\bus\isa\isabusdxe\isabus.c(395) : warning C4703: potentially uninitialized local pointer variable 'DevicePathData' used LINK : fatal error LNK1257: code generation failed The following online messages shows discussions related to this vs2013 issue and how Microsoft engineer responded. They suggest a work around by adding the initialization for the variables. https://connect.microsoft.com/VisualStudio/feedback/details/816730/bogus-warning-from-vs-2013 Vs2013 issue #2: C:\Program Files\Windows Kits\8.1\include\um\winnt.h(5105) : error C2220: warning treated as error - no 'object' file generated C:\Program Files\Windows Kits\8.1\include\um\winnt.h(5105) : warning C4005: 'InterlockedCompareExchange64' : macro redefinition This happened for Nt32Pkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wang, Yu <yu.wang@intel.com> Reviewed-by: Gao, Liming <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15722 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-28BaseTools: Add GCC49 toolchain; align data sections to 0x40Jordan Justen
GCC 4.9 may use 64-byte (0x40) alignment for data sections. Therefore we use a different link script for GCC 4.9. The only difference from the gcc4.4-ld-script is the alignment for data sections. When using the GCC48 toolchain with GCC 4.9, this error would be encountered by GenFw: > GenFw: ERROR 3000: Invalid > Unsupported section alignment. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Yingke Liu <yingke.d.liu@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15697 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-01Sync BaseTool trunk (version r2670) into EDKII BaseTools. Gao, Liming
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gao, Liming <liming.gao@intel.com> Reviewed-by: Liu, Yingke D (yingke.d.liu@intel.com) git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15605 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-27Sync BaseTool trunk (version r2649) into EDKII BaseTools.Gao, Liming
Signed-off-by: Gao, Liming <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15188 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-31 04:39:54 +0000