mirror of
https://github.com/acidanthera/audk.git
synced 2025-04-08 17:05:09 +02:00
214a3b7941
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
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. 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