summaryrefslogtreecommitdiff
path: root/BaseTools
AgeCommit message (Collapse)Author
2016-08-12BaseTools ARM AARCH64: drop redundant compiler argumentsArd Biesheuvel
The ARM and AARCH64 CC_FLAGS definitions include both GCC_ALL_CC_FLAGS and GCC44_ALL_CC_FLAGS, resulting in many of the compiler arguments being passed twice. Since the CLANG35 definitions do not refer to GCC44_ALL_CC_FLAGS, drop the reference for GCCx as well. 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>
2016-08-12BaseTools ARM AARCH64: pass CC flags to linker for XIP modules as wellArd Biesheuvel
Commit 478f50990a ("BaseTools GCC: add the compiler flags to the linker command line") added the compiler flags to the linker command line, which is required for LTO to function correctly, since it involves code generation at link time. This patch failed to update the build rules for XIP modules on AARCH64, which not only requires the ordinary CC flags but also the XIP CC flags to prevent the LTO backend to, e.g., emit code that does not adhere to the strict alignment rules we impose for code that may execute with the MMU off. So update the XIP link rules as well. Since AARCH64 and ARM are not supported by any toolchains in the GCCLD build rule family, drop the reference to GCCLD while we're at 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>
2016-08-12BaseTool/VfrCompile: Remove reset button opcode in CheckQuestionOpCodeDandan Bi
"EFI_IFR_RESET_BUTTON_OP" is a statement, not a question, so remove it from function CheckQuestionOpCode. Cc: Liming Gao <liming.gao@intel.com> Cc: Eric Dong <eric.dong@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
2016-08-10BaseTools-Conf:Introduce CLANG38 new toolchain for x86Shi, Steven
This adds support for LLVM 3.8.x in LTO mode for IA32 and X64. CLANG38 enable LLVM Link Time Optimization (LTO) and code size optimization flag (-Oz) by default for aggressive code size improvement. CLANG38 X64 code is small code model + PIE. CLANG LTO needs PIE in link flags to generate PIE code correctly, otherwise the PIE is not really enabled. (e.g. OvmfPkgX64 will hang in 64bits SEC at high address because of small model code displacement overflow). Test pass platforms: OVMF (OvmfPkgIa32.dsc, OvmfPkgX64.dsc and OvmfPkgIa32X64.dsc). Test compiler and linker version: LLVM 3.8, GNU ld 2.26. Example steps to use the CLANG38 tool chain to build OVMF platform: 1. Download and extract the llvm 3.8.0 Pre-Built Binaries from http://www.llvm.org/releases/ (e.g. http://www.llvm.org/releases/ 3.8.0/clang+llvm-3.8.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz and extract it as ~/clang38). 2. Copy LLVMgold.so from https://github.com/shijunjing/edk2/blob/ llvm/BaseTools/Bin/LLVMgold.so to above clang lib folder (e.g. ~/clang38/lib/LLVMgold.so) 3. Install new version linker with plugin support (e.g. ld 2.26 in GNU Binutils 2.26 or Ubuntu16.04) $ cd edk2 $ git checkout llvm $ export CLANG38_BIN=path/to/your/clang38/ (e.g. export CLANG38_BIN=~/clang38/bin/) $ source edksetup.sh $ make -C BaseTools/Source/C $ build -t CLANG38 -a X64 -p OvmfPkg/OvmfPkgX64.dsc -n 5 -b DEBUG -DDEBUG_ON_SERIAL_PORT $ cd edk2/Build/OvmfX64/DEBUG_CLANG38/FV $ qemu-system-x86_64.exe -bios OVMF.fd -serial file:serial.log -m 4096 -hda fat:. If you want, you can build and install GNU Binutils 2.26 as below steps in Ubuntu: Download binutils-2.26 source code from http://ftp.gnu.org/gnu/binutils/ and extract it to ~/binutils-2.26 $sudo apt-get install bison $sudo apt-get install flex Install other necessary binutils build tools if missing $ mkdir build $ cd build $ ../binutils-2.26/configure --enable-gold --enable-plugins --disable-werror --prefix=/usr $ make -j 5 $ sudo make install If you want, you can build LLVMgold.so as below steps Download llvm-3.8.0 source code from http://www.llvm.org/releases/ 3.8.0/llvm-3.8.0.src.tar.xz and extract it to ~/llvm-3.8.0.src Download clang3.8.0 source code from http://www.llvm.org/releases/ 3.8.0/cfe-3.8.0.src.tar.xz and extract it to ~/llvm-3.8.0.src/tools/clang Refer http://clang.llvm.org/get_started.html to Install other necessary clang build tools if missing $ mkdir llvm38build $ cd llvm38build If your GNU Binutils 2.26 is in /home/jshi19/binutils-2.26, $ cmake ../llvm-3.8.0.src -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Release" -DLLVM_TARGETS_TO_BUILD="X86" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_CXX_COMPILER="/usr/bin/g++" -DCMAKE_C_COMPILER="/usr/bin/gcc" -DLLVM_BINUTILS_INCDIR=/home/jshi19/binutils-2.26/include $ make -j 5 LLVMgold The LLVMgold.so is in ~/llvm38build/lib/LLVMgold.so Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Steven Shi <steven.shi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-08-10BaseTools-Conf:Remove short dash in ar flag for LLVMShi, Steven
Both binutils ar and LLVM ar support "cr", but LLVM ar doens't support add "-" in the flags, and llvm-ar cannot accept "-cr". So remove the short dash "-" to make llvm archives work. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Steven Shi <steven.shi@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-08-09BaseTools ARM: impose strict alignment only for XIP modulesArd Biesheuvel
Given that we only support ARMv7 and up in Tianocore (due to the fact that the PI spec mandates that the PEI services table pointer be stored in the TPIDRURW register, which is not available on earlier CPUs), we can assume that any code executing with the MMU on may perform unaligned accesses (since the AArch32 bindings in the UEFI spec stipulate that unaligned accesses should be allowed if supported by the CPU) So relax the alignment restrictions to XIP modules only, i.e., BASE, SEC, PEI_CORE and PEIM type modules, exactly like we do for AARCH64 already. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-08-09BaseTools CLANG35: add missing XIP flags for AARCH64Ard Biesheuvel
When building for AARCH64, code that may execute with the MMU off should not perform unaligned accesses, which is why we set -mstrict-align for BASE, SEC, PEI_CORE and PEIM modules when building with GCCx. However, this setting is missing from CLANG35 so set it there as well. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-08-09BaseTools/UPT: Fix a install issueHess Chen
Fix a corner case issue of installing a module without any files which causes installing UNI file failure Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hess Chen <hesheng.chen@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
2016-08-08BaseTools X64: fold PLT relocations into simple relative referencesArd Biesheuvel
For X64/GCC, we use position independent code with hidden visibility to inform the compiler that symbol references are never resolved at runtime, which removes the need for PLTs and GOTs. However, in some cases, GCC has been reported to still emit PLT based relocations, which we need to handle in the ELF to PE/COFF perform by GenFw. Unlike GOT based relocations, which are non-trivial to handle since the indirections in the code can not be fixed up easily (although relocation types exist for X64 that annotate relocation targets as suitable for relaxation), PLT relocations simply point to jump targets, and we can relax such relocations by resolving them using the symbol directly rather than via a PLT entry that does nothing more than tail call the function we already know it is going to call (since all symbol references are resolved in the same module). So handle R_X86_64_PLT32 as a R_X86_64_PC32 relocation. Suggested-by: Steven Shi <steven.shi@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-08-08BaseTools/VfrCompile: Add two new option for VfrCompileDandan Bi
1.--autodefault option VfrCompile will generate default opcodes for questions if some default are missing. 2 --checkdefault option VfrCompile will check whether every question has no default or has all default. If not, will generate an error to let user know the question misses default. Cc: Liming Gao <liming.gao@intel.com> Cc: Eric Dong <eric.dong@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
2016-08-08BaseTool/VfrCompile: Add missing question opcodeDandan Bi
The function CheckQuestionOpCode is to check whether the opcode is question opcode, but it misses two question opcodes: 'EFI_IFR_REF_OP' and 'EFI_IFR_RESET_BUTTON'. Now add them. Cc: Liming Gao <liming.gao@intel.com> Cc: Eric Dong <eric.dong@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
2016-08-08BaseTools: Fix the bug when use FILE_GUID override the module in DSCYonghong Zhu
In last commit 2502b73, it doesn't cover the case that in the DSC file use FILE_GUID to override the module. 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: Liming Gao <liming.gao@intel.com>
2016-08-08BaseTools: Allow string token identifier to use lower case lettersYonghong Zhu
This patch is to align the code behavior with UNI spec that string token identifier can use upper case and lower case letters. Cc: Liming Gao <liming.gao@intel.com> Cc: Felix <Felixp@ami.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-08-05BaseTools GCC/ARM: add -fno-builtin to CC flagsArd Biesheuvel
Avoid build errors when including OpensslLib, which may throw undefined reference errors for builtin functions if -fno-builtin is not specified (and it is already set for IA32, X64 and AARCH64) So set it for ARM as well. 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>
2016-08-03BaseTools GCC: add the compiler flags to the linker command lineArd Biesheuvel
Now that we invoke GCC as the linker for the GCC toolchain family, we can pass the CC flags to the linker as well. This is only required for LTO (which may involve code generation during the link stage), but does not interfere with non-LTO builds. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-08-03BaseTools GCC5: disable warnings-as-errors for nowArd Biesheuvel
GCC5 runs in LTO mode, which means it may generate code from an intermediate representation during the link stage, at which time additional diagnostics are run that may emit warnings. Some of these warnings seem to be spurious, e.g., the following warning which is emitted when building OVMF for IA32 or ArmVirtQemu for ARM (but not for X64 resp. AARCH64) .../MdeModulePkg/Library/UefiHiiLib/HiiLib.c: In function 'HiiCreateGuidOpCode.constprop': .../MdeModulePkg/Library/UefiHiiLib/HiiLib.c:3228:10: error: function may return address of local variable [-Werror=return-local-addr] return (UINT8 *)OpCodePointer; ^ .../MdeModulePkg/Library/UefiHiiLib/HiiLib.c:3208:17: note: declared here EFI_IFR_GUID OpCode; ^ lto1: all warnings being treated as errors lto-wrapper: fatal error: gcc returned 1 exit status So before adding the contents of CC_FLAGS to the linker command line, defuse the default '-Werror' by adding '-Wno-error' to DLINK2_FLAGS for GCC5. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-08-03BaseTools GCC: move -c compiler flag to build rulesArd Biesheuvel
In order to be able to share the compiler flags with the linker (which is required for LTO since it involves the linker doing code generation based on the LTO bytecode), move the -c GCC argument to the build rules, and drop it from the GCC CC_FLAGS definitions in tools_def. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-08-03BaseTool/Upt: Avoid UNI file name conflictHess Chen
When creating a UNI file if there is a name conflict, add an index from 0 to the file name Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hess Chen <hesheng.chen@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
2016-08-03BaseTool/UPT: Not expand macro for UserExtensionHess Chen
All MACRO values defined by the DEFINE statements n any section (except [Userextensions] sections other than TianoCore."ExtraFiles) of the INF or DEC file must be expanded before processing of the file. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hess Chen <hesheng.chen@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
2016-08-03BaseTool/Upt: Add support for PrivateHess Chen
Support new syntax in package DEC file as below: [Includes.Common.Private] [Ppis.Common.Private] [Guids.Common.Private] [Protocols.Common.Private] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hess Chen <hesheng.chen@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
2016-08-03BaseTool/UPT: Add Test InstallHess Chen
Add a new function to test if a DIST file list one by one to see if they can meet the requirement of Dependency. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hess Chen <hesheng.chen@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
2016-08-02BaseTools: Keep the Pcd order in the Asbuilt Inf is same with SourceYonghong Zhu
The original behavior is that in the Asbuilt inf Pcd's order is base on the Pcd's offset. Now we change the order to keep it is same with the Pcd order in the source inf file. 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: Liming Gao <liming.gao@intel.com>
2016-08-02BaseTools AARCH64: override XIP module linker alignment to 32 bytesArd Biesheuvel
Now that GenFw converts small code model ADRP instructions to ADR on the fly, we can reduce the alignment for XIP modules, where large alignment values may cause considerable waste of flash space due to excessive padding. This limits the module size to 1 MB, but this is not a concern in practice. So set the XIP section alignment to 0x20 for DEBUG_GCC49, DEBUG_GCC5 and *_CLANG35, all of which use the small code model. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2016-08-02BaseTools/GenFw AARCH64: convert ADRP to ADR instructions if binary size ↵Ard Biesheuvel
allows it The ADRP instruction in the AArch64 ISA requires the link time and load time offsets of a binary to be equal modulo 4 KB. The reason is that this instruction always produces a multiple of 4 KB, and relies on a subsequent ADD or LDR instruction to set the offset into the page. The resulting symbol reference only produces the correct value if the symbol in question resides at that exact offset into the page, and so loading the binary at arbitrary offsets is not possible. Due to the various levels of padding when packing FVs into FVs into FDs, this alignment is very costly for XIP code, and so we would like to relax this alignment requirement if possible. Given that symbols that are sufficiently close (within 1 MB) of the reference can also be reached using an ADR instruction which does not suffer from this alignment issue, let's replace ADRP instructions with ADR after linking if the offset can be encoded in this instruction's immediate field. Note that this only makes sense if the section alignment is < 4 KB. Otherwise, replacing the ADRP has no benefit, considering that the subsequent ADD or LDR instruction is retained, and that micro-architectures are more likely to be optimized for ADRP/ADD pairs (i.e., via micro op fusing) than for ADR/ADD pairs, which are non-typical. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2016-08-02BaseTools GCC: introduce GCC5 toolchain to support GCC v5.x in LTO modeArd Biesheuvel
This adds support for GCC 5.x in LTO mode for IA32, X64, ARM and AARCH64. Due to the fact that the GCC project switched to a new numbering scheme where the first digit is now incremented for every major release, the new toolchain is simply called 'GCC5', and is intended to support all GCC v5.x releases. Since IA32 and X64 enable compiler optimizations (-Os) for both DEBUG and RELEASE builds, LTO support is equally enabled for both targets. On ARM and AARCH64, DEBUG builds are not optimized, and so the LTO optimizations are only enabled for RELEASE. 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: Liming Gao <liming.gao@intel.com>
2016-08-02BaseTools GCC: drop GNU notes section from EFI imageArd Biesheuvel
Recent versions of GNU ld automatically emit a .notes section into the ELF binary containing a build id. Since this is an allocatable section by default, it will be identified by GenFw as a section that requires PE/COFF conversion, which may cause sections to be moved around unexpectedly. So retain the section, but tag it as INFO, which tells the linker that it should not be accounted for in the binary's memory layout. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-08-02BaseTools GCC: use 'gcc' as the linker command for GCC44 and laterArd Biesheuvel
To accommodate upcoming GCCx toolchain versions that require 'gcc' to be used as the linker in order to support LTO, switch GCC44 and later (including CLANG35) to a new DLINK build rule that invokes 'gcc' as the linker instead of 'ld'. Since gcc expects its command line arguments in a different format, and expects arguments that it needs to pass to the linker to be prefixed with '-Wl,', this involves changes to most of the DLINK_FLAGS definitions in tools_def.template, as well as some changes to module .INF files that set their own linker options. 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: Liming Gao <liming.gao@intel.com>
2016-08-02BaseTools UNIXGCC ELFGCC CYGGCC: clone GCC build rule family into GCCLDArd Biesheuvel
Before we can make non-backward compatible changes to the GCC build rules regarding the use of the 'gcc' binary as the linker, clone the existing GCC build rules into a 'GCCLD' build rule family, and move the legacy toolchains UNIXGCC, CYGGCC, CYGGCCxASL and ELFGCC over to it. 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: Liming Gao <liming.gao@intel.com>
2016-08-02BaseTools CLANG35: drop problematic use-movt and save-temps optionsArd Biesheuvel
Some versions of Clang fail on every input file when using the -save-temps options, and produces the following heplful error message: <unknown>:0: error: Undefined temporary symbol Simply dropping the option for CLANG35 is the simplest way around this, since the value of storing .i and .s files is dubious anyway. Also, drop the arm-use-movt option, which does not appear to be supported anymore by recent versions of clang. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2016-07-29BaseTools/Ecc: GUID checkpointHess Chen
Fix a bug of checking duplicate GUID Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hess Chen <hesheng.chen@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
2016-07-29BaseTools: Add build info for binary modules that only list in FDF fileYonghong Zhu
If the binary module is list in the FDF file but not list in the DSC file, current build report would not include these binary module's info in the report "Module section". The patch fix this issue. 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: Liming Gao <liming.gao@intel.com>
2016-07-29BaseTools: Correct ReadMe.txt file with CRLF line endingLiming Gao
Cc: Yonghong Zhu <yonghong.zhu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao <liming.gao@intel.com>
2016-07-27BaseTools: report error if source module INF is only list in FDF fileYonghong Zhu
If source module INF is not listed in DSC, it will not be built. And it is listed in FDF, GenFds will fail to find its build output. To reminder user this issue early, build tool should report failure to user in early phase. 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: Liming Gao <liming.gao@intel.com>
2016-07-26BaseTools/toolsetup.bat: Fix bug caused by 'CONF_PATH' not definedHao Wu
In batch script files, setting a variable in an 'if' block will only take effect after the 'if' block. This commit fixes the issue of using the variable 'CONF_PATH' right after it is being set in an 'if' block. Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-07-26BaseTools/toolsetup: Do not set CONF_PATH when already set.Marvin Haeuser
When CONF_PATH is already set, toolsetup.bat overwrites its value. This is not the case on Linux platforms (BuildEnv) and contra-productive when using the same Workspace across multiple Operating Systems. With this patch, a check is performed prior to setting the variable. Furthermore, it will not be scanned for Conf directories in PACKAGES_PATH directories to respect the user's choice. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
2016-07-26Preserve hii section in GCC binariesThomas Palmer
According to UEFI spec: Once an image is loaded, LoadImage() installs EFI_HII_PACKAGE_LIST_PROTOCOL on the handle if the image contains a custom PE/COFF resource with the type 'HII'. The protocol's interface pointer points to the HII package list which is contained in the resource's data. This is controlled by the UEFI_HII_RESOURCE_SECTION define in the INF file. When present the HII resource is linked with the module binary. Unfortunately GCC-built binaries have been stripping the .hii section entirely. See "[edk2] HII gEfiHiiPackageListProtocolGuid problem with GCC48(VS2012x86 works)" http://thread.gmane.org/gmane.comp.bios.tianocore.devel/13438 http://thread.gmane.org/gmane.comp.bios.tianocore.devel/14899 This patch tells the linker to preserve the .hii sections Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Palmer <thomas.palmer@hpe.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Bruce Cran <bruce.cran@gmail.com> Reviewed-by: Bruce Cran <bruce.cran@gmail.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-07-21BaseTools/tools_def: switch GCC/X64 to the PIE small modelArd Biesheuvel
The ordinary small code model for x86_64 cannot be used in UEFI, since it assumes the executable is loaded in the first 2 GB of memory. Therefore, we use the large model instead, which can execute anywhere, but uses absolute 64-bit wide quantities for all symbol references, which is costly in terms of code size. So switch to the PIE small code model, this uses 32-bit relative references where possible, but does not make any assumptions about the load address (i.e., all absolute symbol references are 64-bits wide). Note that, due to the 'protected' visibility pragma introduced in an earlier patch, there is no need for the EDK2 build system to deal with GOT related ELF relocation types. 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: Laszlo Ersek <lersek@redhat.com> Tested-By: Liming Gao <liming.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-07-21BaseTools/tools_def: enable Os optimization for GCC X64 buildsArd Biesheuvel
Now that we switched to the __builtin_ms_va_list VA_LIST type for GCC/X64, we can trust the compiler to do the right thing even under optimization, and so we can enable -Os optimization all the way back to GCC44, and drop the -D define that prevents the use of the __builtin VA_LIST types. Note that this requires the -maccumulate-outgoing-args switch as well. 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: Laszlo Ersek <lersek@redhat.com> Tested-By: Liming Gao <liming.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-07-18BaseTools/tools_def.template: bump minimum required NASM versionsLaszlo Ersek
NASM had been unable to assemble segment register operations before the following git commit: http://repo.or.cz/nasm.git/commitdiff/21d4ccc3c338 That commit was first released in NASM 2.10: http://repo.or.cz/nasm.git/commitdiff/ff62f33da0a2 This makes NASM 2.07 unusable for edk2 in general, because now we have a lot of X64 assembly code that works with segment registers. For example in: UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm Bump the minimum required version to 2.10, for use with GCC toolchains. Furthermore, list NASM 2.12.01 as a requirement for all other toolchains. In particular, for source level debugging, VS20xx requires CodeView 8 debug symbols, and only NASM 2.12.01 and later produce those. (Suggested by Liming, Mike, and Andrew.) Cc: Andrew Fish <afish@apple.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/14612 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-07-18BaseTools: Fix a bug for FixedPcd value generation in AutoGen fileYonghong Zhu
If the library is listed in [Components] section for build only, its used FixedPcd Value is not generated into AutoGen code. This patch cover this case to generate the FixedPcd Value in AutoGen file. 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: Liming Gao <liming.gao@intel.com>
2016-07-14BaseTools: Update the FV region name as upper letterYonghong Zhu
Since in the GenFds phase, the FV is generated as upper letter. This patch update the FV region name as upper letter, it can fix the build report generate failure on case sensitive file system. 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: Liming Gao <liming.gao@intel.com> Reviewed-by: Andrew Fish <afish@apple.com>
2016-07-12BaseTools/GenFds: unbreak Region.PadBufferLaszlo Ersek
In its current form, Region.PadBuffer() fills every second byte with 0x20, the default separator string of Python's string.join(): https://docs.python.org/2/library/string.html#string.join This corrupts some firmware because (a) 0x20 never corresponds to any ErasePolarity, (b) the PadData produced are actually longer than Size. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Fixes: bd907fb6386560e621112beca7b7d381d0003967 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-07-12BaseTools/GenFds: speed up Region.PadBuffer()Laszlo Ersek
The current implementation calls both pack() and Buffer.write() Size times. The new implementation calls both of these methods only once; the full data to write are constructed locally [1]. The range() function is replaced by xrange() because the latter is supposed to be faster / lighter weight [2]. On my laptop, I tested the change as follows: I pre-built the series at [3] with build -a X64 -p OvmfPkg/OvmfPkgX64.dsc -t GCC48 -b DEBUG \ -D HTTP_BOOT_ENABLE -D SECURE_BOOT_ENABLE (The series at [3] is relevant because it increases the size of one of the padded regions by 8.5 MB, slowing down the build quite a bit.) With all source code already compiled, repeating the above command takes approximately 45 seconds. With the patch applied, it goes down to 29 seconds. [1] http://stackoverflow.com/questions/27384093/fastest-way-to-write-huge-data-in-file [2] https://docs.python.org/2/library/functions.html?highlight=xrange#xrange [3] http://thread.gmane.org/gmane.comp.bios.edk2.devel/14214 We can also measure the impact with a synthetic test: > import timeit > > test_old = """ > import struct, string, StringIO > Size = (8 * 1024 + 512) * 1024 > Buffer = StringIO.StringIO() > PadData = 0xFF > for i in range(0, Size): > Buffer.write(struct.pack('B', PadData)) > """ > > test_new = """ > import struct, string, StringIO > Size = (8 * 1024 + 512) * 1024 > Buffer = StringIO.StringIO() > PadByte = struct.pack('B', 0xFF) > PadData = string.join(PadByte for i in xrange(0, Size)) > Buffer.write(PadData) > """ > > print(timeit.repeat(stmt=test_old, number=1, repeat=3)) > print(timeit.repeat(stmt=test_new, number=1, repeat=3)) The output is [8.231637001037598, 8.81188416481018, 8.948754072189331] [0.5503702163696289, 0.5461571216583252, 0.578315019607544] Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-07-12BaseTools/GenFds: factor out Region.PadBuffer() methodLaszlo Ersek
The same logic is used in five places; factor it out to a common method. Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-07-05BaseTools MemoryProfileSymbolGen.py: Handle 64bits rva from "nm -l xxx.dll"Star Zeng
Current MemoryProfileSymbolGen.py assumes the rva is 32bits, the patch is to remove the restriction to match any lengths of rva. Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2016-07-05BaseTools: Add support for $(FAMILY) macroYonghong Zhu
Build spec mentions $(FAMILY) macro be used in DSC/FDF to specify the tool chain family, like GCC, MSFT. This patch add the support for this macro. 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: Liming Gao <liming.gao@intel.com>
2016-07-01BaseTools Scripts: Add MemoryProfileSymbolGen.pyStar Zeng
This tool depends on DIA2Dump.exe (VS) or nm (gcc) to parse debug entry. Usage: MemoryProfileSymbolGen.py [--version] [-h] [--help] [-i inputfile [-o outputfile]] Copyright (c) 2016, Intel Corporation. All rights reserved. Options: --version show program's version number and exit -h, --help show this help message and exit -i INPUTFILENAME, --inputfile=INPUTFILENAME The input memory profile info file output from MemoryProfileInfo application in MdeModulePkg -o OUTPUTFILENAME, --outputfile=OUTPUTFILENAME The output memory profile info file with symbol, MemoryProfileInfoSymbol.txt will be used if it is not Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2016-06-28BaseTools ConvertMasmToNasm: Don't try to reconvert .nasm filesJordan Justen
We now check to see if the destination .nasm file already exists. If it does, then we don't try to convert the .asm to .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>
2016-06-28BaseTools ConvertMasmToNasm: Support preserving assembly filesJordan Justen
In the first stage of conversion, we need to preserve the AT&T style .s assembly files for use with OS X toolchains. This change allows '--keep=s' to be used with the script to preserve these files. 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>
2016-06-28BaseTools ConvertMasmToNasm: put filter/map result in tuple for python3Jordan Justen
Python 3's filter and map functions returns an iterator which you can't call len() on. Since we'll want to use len() later, we put the filter results into a tuple. 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>