| Age | Commit message (Collapse) | Author |
|---|
|
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Guo Mang <mang.guo@intel.com>
|
|
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>
(cherry picked from commit 3e1d93c32efc7d716baeaa0d5d0ef96528141060)
|
|
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>
(cherry picked from commit bdaced0bcf9a15817fbab4e7b98200cf6628b7a5)
|
|
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>
(cherry picked from commit ab200776cdba018c4b6e5f712628482d46ba4931)
|
|
Now, -fno-builtin option is added for the specific GCC tool chain.
It is a generic option. It can be moved to common GCC option to keep
the consistent compiler option.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
|
|
As a security measure, some distro toolchains now default to PIC code
generation, allowing executables (as opposed to shared libraries) using
the objects to be built as PIE binaries, which can be loaded at a random
virtual offset.
However, our ELF to PE/COFF generation code does not deal with the
resulting relocation types (i.e., GOT based), and so the use of PIC code
leads to GenFw errors.
Given that
a) our non-PIC PE/COFF executables are already relocatable,
b) PIC code leads to all symbol references to be indirected via GOT
entries containing absolute addresses, each requiring an entry in the
relocation table,
c) the AArch64 ISA makes it perfectly feasible to built PIE executables
from non-PIC code,
there is absolutely no upside to using PIC code for building EDK2 modules,
and so we're better off simply disabling it unconditionally.
Note that when running under the OS, the GOT has an additional advantage,
i.e., that all .text/.rodata pages remain clean and so can be shared between
processes. This does not apply to the UEFI environment, however.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
|
|
- Add Brotli algorithm tool support
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bell Song <binx.song@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
|
|
Define "-march=armv7-a" - which is used by the GCC toolchains - for
ARM CLAMNG35 builds to fix compilation of the MemoryFence ASM.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
https://bugzilla.tianocore.org/show_bug.cgi?id=310
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>
|
|
https://bugzilla.tianocore.org/show_bug.cgi?id=227
Refer to VS ASLPP_FLAGS, force include AutoGen.h so that ASL code
can use FixedPcdGetXX to get FixedPcd value.
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>
|
|
https://bugzilla.tianocore.org/show_bug.cgi?id=227
After -P option is removed, the generated preprocessed ASL file will have
line markers. The extra information can be removed by Trim script. ASL code
can refer to the definition in C source file. This has been supported in
VS and XCODE tool chains.
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>
|
|
This patch introduce PREFIX env for VS tool path for tools_def.template
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>
|
|
Update the tools_def.template to add NOOPT support with GCC tool chains.
Also disable -flto and -Os in NOOPT target for GCC5.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.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: Laszlo Ersek <lersek@redhat.com>
Tested-by: Bruce Cran <bruce.cran@sandisk.com>
|
|
BaseTools add support to generating image package from BMP/JPEG/PNG
files.
1) New file type *.idf Image definition file to describe HII image
resource. It is the ASCII text file, and includes one or more "#image
IMAGE_ID [TRANSPARENT] ImageFileName".
2) New IMAGE_TOKEN macro is used to refer to IMAGE_ID.
3) New AutoGen header file $(MODULE_NAME)ImgDefs.h to include the
generated ImageId definition.
4) New $(MODULE_NAME)Idf.hpk or $(MODULE_NAME)Images are generated
as the output binary HII image package.
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>
|
|
Enable frame pointers on DEBUG builds so we can support backtraces in
crash dumps.
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>
|
|
Provide the PKCS7 Tool to support the CertType - EFI_CERT_TYPE_PKCS7_GUID,
then user can use this tool to add EFI_FIRMWARE_IMAGE_AUTHENTICATION
for a binary.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
|
|
CLANG38 build fail after CC_FLAG is added in the link rule.
This failure is because the CLANG38 enable the LTO through LLVMgold.so
linker plugin, but the LLVMgold.so plugin cannot accept the clang -Oz
CC flag as build option. After CC_FLAG is added in the link rule,
the LLVMgold.so plugin reports linking error. LLVMgold.so only accept
-O0 ~ -O3, and you can see it in the LLVM gold plugin source code
in below:
http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_380/final/tools/gold/
gold-plugin.cpp line173:
if (opt[1] < '0' || opt[1] > '3')
message(LDPL_FATAL, "Optimization level must be between 0 and 3");
Add -O3 in the *_CLANG38_*_DLINK2_FLAGS to override the -Oz flag in
*_CLANG38_*_CC_FLAGS to pass LLVMgold.so linking.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi <steven.shi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
|
|
This updates the RVCT CC flags so various diagnostics that trigger
warnings-as-errors are silenced. In particular, RVCT complains about
missing newlines at the end of source files, mixing of enums and int
values and return statements followed by a break, all of which occur
in the Tianocore codebase, but none of which are actual errors in the
code. So just silence them.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
By default, the ARM architectures have unsigned chars, whereas the other
architectures supported by EDK2 by default have signed chars.
However, EDK2 uses -funsigned-chars on those architectures to change the
default behaviour.
Unfortunately, the ARM architectures explicitly break their default
behaviour by specifying -fsigned-chars (I presume in a pre-emptive
attempt at avoiding incompatibility).
Since this situation is already confusing enough, switch the ARM
architectures to also specify -funsigned-chars explicitly rather than
just dropping the current parameter.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
|
|
Remove /Oi from Visual Studio tool chains. because of the following reasons:
1. Intrinsic is Compiler-dependent.
2. Adding /Oi (Generate Intrinsic Functions) doesn't promise 100% replacing
the function call with inline functions.
/Oi is only a request, but doesn't force, the compilers to use the intrinsic.
The visual studio optimizer can still use the library version.
3. Since EDK2 doesn't include Visual Studio header files, intrinsic function
should not be used.
Built Nt32Pkg, OvmfPkg, ShellPkg, MdeModulePkg and CryptoPkg successfully.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Qin Long <qin.long@intel.com>
|
|
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>
|
|
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>
|
|
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>
|
|
There are no functional changes in this patch.
The only change is to the XML format, updated using Visual Studio
Edit->Advanced->Format Document.
Different XML Schema editors use different formats for indentation and
line breaks. Visual Studio 2013 uses a two space indentation for content.
Cc: Zhu Yonghong <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Larry Hauch <larry.hauch@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
|
|
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
|
|
This introduces a special .c to .obj build rule for GCC/AARCH64 that
takes into account additional compiler flags that have been specified
via *_*_*_CC_XIPFLAGS. These will be passed after (and in addition to)
the ordinary 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@19637 6f19259b-4bc3-4df7-8a09-765794883524
|
|
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
|
|
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
|
|
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.
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@19284 6f19259b-4bc3-4df7-8a09-765794883524
|
|
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.
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/trunk/edk2@19235 6f19259b-4bc3-4df7-8a09-765794883524
|
|
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.
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/trunk/edk2@19164 6f19259b-4bc3-4df7-8a09-765794883524
|
|
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/trunk/edk2@19101 6f19259b-4bc3-4df7-8a09-765794883524
|
