5397bd425e
clang generates many warnings warning: field 'XXX' is uninitialized when used here [-Wuninitialized] for VfrFormPkg.h. VfrFormPkg.h defines many classes derived from CIfrObj (along with other base classes.) Each of these derived classes defines a non-static member field that serves as a duplicate pointer to an original pointer defined in the CIfrObj base class, but cast to a different pointer type. The derived class constructor passes the duplicate pointer to base class constructors: 1) Once passes the address of the duplicate pointer to the CIfrObj constructor to have it initialized. 2) Then passes the duplicate pointer to one or more subsequent base class constructors to be used. Both 1) and 2) constitute undefined behavior in C++. C++ prescribes that base classes are initialized before non-static members when initializing a derived class. So when base class constructors are executing, it is not permitted to assume any non-static members of the derived class exist (even to the stage of having their storage allocated.) clang does not issue warnings for 1), but issues warnings -Wuninitialized for 2). This coding methodology is resolved as follows: a) The CIfrObj object accessor method for retrieving the original pointer is revised to a template member function that returns the original pointer cast to a desired target type. b) The call to CIfrObj constructor is no longer used to initialize the duplicate pointer in the derived class. c) Any subsequent calls to a base class constructor that need to use the pointer, retrieve it from the CIfrObj base class using the template accessor method. d) If the derived class makes no further use of the pointer, then the duplicate pointer defined in it is eliminated. e) If the derived class needs the duplicate pointer for other use, the duplicate pointer remains in the derived class and is initialized in proper order from the original pointer in CIfrObj. f) Existing source code that previously used the CIfrObj pointer accessor method is revised to use the template method. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Zenith432 <zenith432@users.sourceforge.net> Reviewed-by: Liming Gao <liming.gao@intel.com>
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