9ba8baae15
On AARCH64, any code that may execute with the MMU off needs to be built
with -mstrict-align, given that unaligned accesses are not allowed unless
the MMU is enabled. This does not only affect SEC and PEI modules, but
also static libraries of the BASE type, which may be linked into such
modules, as well as into modules of other types. As it turns out, the
presence of -mstrict-align is reflected in the internal representations
of the types defined in those libraries.
When -fstrict-aliasing is passed to GCC, it assumes that pointers to
objects of different types cannot refer to the same memory location, and
attempts to exploit this fact when optimizing the code. Since such
assumptions are only valid under very strict conditions which are not
guaranteed to be met in EDK2, we disable this optimization by passing
-fno-strict-aliasing by default. [*]
When LTO is in effect, this applies equally to the code generation that
may occur at link time, which is why the linker warns about unexpected
differences in type definitions between the intermediate representations
that are present in the object files being linked. This may result in
warnings such as the one below, even if -fno-strict-aliasing is used:
MdePkg/Include/Library/BaseLib.h:1712:1:
warning: type of 'StrToGuid' does not match original declaration
[-Wlto-type-mismatch]
StrToGuid (
^
MdePkg/Library/BaseLib/SafeString.c:1506:1:
note: 'StrToGuid' was previously declared here
StrToGuid (
^
MdePkg/Library/BaseLib/SafeString.c:1506:1:
note: code may be misoptimized unless -fno-strict-aliasing is used
This warning is inadvertently triggered when linking BASE libraries built
with -mstrict-align into modules of types other than SEC or PEI, since the
types are subtly different, even though the use of code that maintains
strict alignment in a module that does not care about this is unlikely to
cause problems. And even if it did, it would still only affect code built
with -fstrict-aliasing enabled, which we disable unconditionally. So let's
just silence the warning by passing -Wno-lto-type-mismatch.
[*] Leif adds: "-fstrict-aliasing is GCC default, because it is a
restriction in the C language. Because it's a bit non-obvious, things
can go hilariously wrong in very non-obvious ways, and the potential
optimization gains are unlikely to be generally relevant,
-fno-strict-aliasing is a sensible thing to always have set (like we
do)."
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
This directory contains the next generation of EDK II build tools and template files. Templates are located in the Conf directory, while the tools executables for Microsoft Windows 32-bit Operating Systems are located in the Bin\Win32 directory, other directory contatins tools source. 1. Build step to generate the binary tools. === Windows/Visual Studio Notes === To build the BaseTools, you should run the standard vsvars32.bat script from your preferred Visual Studio installation or you can run get_vsvars.bat to use latest automatically detected version. In addition to this, you should set the following environment variables: * EDK_TOOLS_PATH - Path to the BaseTools sub directory under the edk2 tree * BASE_TOOLS_PATH - The directory where the BaseTools source is located. (It is the same directory where this README.txt is located.) * PYTHON_FREEZER_PATH - Path to where the python freezer tool is installed After this, you can run the toolsetup.bat file, which is in the same directory as this file. It should setup the remainder of the environment, and build the tools if necessary. Please also refer to the 'BuildNotes.txt' file for more information on building under Windows. === Unix-like operating systems === To build on Unix-like operating systems, you only need to type 'make' in the base directory of the project. === Ubuntu Notes === On Ubuntu, the following command should install all the necessary build packages to build all the C BaseTools: sudo apt-get install build-essential uuid-dev === Python sqlite3 module === On Windows, the cx_freeze will not copy the sqlite3.dll to the frozen binary directory (the same directory as build.exe and GenFds.exe). Please copy it manually from <PythonHome>\DLLs. The Python distributed with most recent Linux will have sqlite3 module built in. If not, please install sqlit3 package separately. 26-OCT-2011