summaryrefslogtreecommitdiff
path: root/BaseTools/Source/C/VfrCompile
AgeCommit message (Collapse)AuthorFilesLines
2025-08-22BaseTools/VfrCompile: Add check for setting string default to numberGao Qihang1-2/+3
It's illegal that string default is numeric type in vfr string definition. This patch add a check to the illegal behavior. If numeric string default is encountered, throw a invalid parameter error to break VfrCompile. Cc: Chao Li <lichao@loongson.cn> Signed-off-by: Gao Qihang <gaoqihang@loongson.cn>
2025-06-07BaseTools: Add support for mingw-w64Nate DeSimone3-13/+36
Adds support for building the C language BaseTools for Windows using toolchains based on mingw-w64. Mingw-w64 is a collection of header files, libraries, and tools that when combined with a compiler enable development of Windows software. Mingw-w64 is a fork of the original MinGW (Minimalist GNU for Windows). Most active development on MinGW has ceased and mingw-w64 is now the actively maintained successor. Mingw-w64 provides a libc implementation built on top of Microsoft's UCRT (Universal C Runtime) with all nessesary compiler bindings needed to support the C++11 feature set. Modern mingw-w64 development appears to have coalesced around MSYS2, which produces a distributions of both GCC and LLVM/Clang that use mingw-w64 to target the Windows OS. This MSYS2 Clang distribution has a UNIX-like directory layout and includes Windows binaries of GNU Make. Combined with the open source licensing, MSYS2's Clang distribution is a highly attractive choice as an alternative Windows SDK for open source projects such as TianoCore. If one wishes to use EDK II to build UEFI firmware on the Windows platform, then the C BaseTools need to be compiled as Windows applications. This includes the PcdValueInit.exe program, which needs to be recompiled every time a firmware build is run in order to regenerate the initial values for structured PCDs. Currently, BaseTools only supports the Visual C++ toolchain on the Windows platform. The following new features have been added to enable usage of the toolchains derived from mingw-w64: - Fixes to the BaseTools C source code to support the use of a GCC-style compiler on the Windows OS. - The GNU Make-style Makefiles for the C BaseTools have been modified to support Windows. Both GCC + mingw-w64 and Clang + mingw-w64 have been tested and confirmed to build a working BaseTools. - BaseTools now supports generating GNU Make-style Makefiles on the Windows platform for the purpose of building firmware. - edksetup.bat has been modified to optionally build BaseTools via mingw-w64. There is no impact to the existing support for Visual C++ and Visual C++ remains the default toolchain. Usage Instructions: For the vast majority of users, the only system setup change nessesary to use a mingw-w64 toolchain is to set the BASETOOLS_MINGW_PATH to the directory containing the desired mingw-w64 based toolchain. A new command line argument has been added to edksetup.bat: Mingw-w64 If this command line argument is set, then the script will set the BASETOOLS_MINGW_BUILD environment variable. The user can also opt to set this environment variable manually before running edksetup.bat If BASETOOLS_MINGW_BUILD is defined, then the BASETOOLS_MINGW_PATH environment variable must point to the directory containing the mingw-w64 toolchain. If CLANG_BIN is not defined and %BASETOOLS_MINGW_PATH%\bin\clang.exe exists, then edksetup.bat will set CLANG_BIN=%BASETOOLS_MINGW_PATH%\bin\ This removes the requirement to configure the CLANG_BIN environment variable manually in order to run a CLANGPDB or CLANGDWARF build if one has the MSYS2 Clang distribution installed. If one wishes to use a different copy of Clang (for example official LLVM binaries) to build firmware and only use the MSYS2 Clang to build BaseTools, then one can continue to set the CLANG_BIN environment variable, same as before. I have tested the MSYS2 Clang distribution against the official LLVM distribution and can confirm that if the compiler version is the same the emitted machine code is identical between the two. Interestingly, the MSYS2 Clang distribution emits the path to the PDB file using "/" as the path seperator instead of "\". That appears to be the only difference in output. Therefore, using the MSYS2 Clang distribution to compile firmware seems a reasonable choice. If CLANG_HOST_BIN is not defined and BASETOOLS_MINGW_BUILD is defined and %BASETOOLS_MINGW_PATH%\bin\mingw32-make.exe exists, then edksetup.bat will add %BASETOOLS_MINGW_PATH%\bin\ to the PATH and set CLANG_HOST_BIN=mingw32- This enable usage of the GNU Make included in the mingw-w64 toolchain to build firmware in addition to BaseTools. if BASETOOLS_MINGW_BUILD is not defined, edksetup.bat will continue to set CLANG_HOST_BIN=n, which uses nmake to build firmware. This behavior can be overridden by manually setting the value of CLANG_HOST_BIN before executing edksetup.bat if one wishes to use a specific Make utility for the CLANGPDB/CLANGDWARF toolchains. References: - https://www.mingw-w64.org/ - https://www.msys2.org/ Co-authored-by: Sandesh Jain <sandesh.jain@intel.com> Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
2025-04-29BaseTools: Add support for GCC preprocessor line directivesNate DeSimone1-1/+2
This change adds support for GCC-style preprocessor line directives as documented in: https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html On Windows systems, one can use line-markers to see which .vfr file was used to generate a *.i file in the Build directory. This is useful for debugging VFR compilation failures. With this change, the VfrCompiler will not generate compilation errors if the *.i file contains GCC-style line-markers. Without this change, one must disable the pre-processor's emission of line-markers, removing the debug aid they provide. Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
2025-01-31BaseTools/Pccts: set C standardGerd Hoffmann2-2/+2
The prehistoric code base doesn't build with ISO C23. Set the C standard to C11 (for both clang and gcc) so it continues to build with gcc 15 (which uses C23 by default). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2024-12-21BaseTools: Adding cross compilation of BaseTool for Windows ARM/ARM64Kun Qin2-6/+24
This change adds the support of crossbuilding basetool for Windows ARM/ ARM64 systems, which will enable the generally available pipeline agents to build binary tools and make releases as they see fit. The EDK2 base tools build script is also updated to support cross compilation using this script. The crossbuilt binary output is tested on Windows ARM based hardware systems. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Kun Qin <kun.qin@microsoft.com>
2023-04-06BaseTools: Update antlr makefile to use cc by defaultRebecca Cran1-5/+0
Update the antlr makefile to remove the explicit setting of CC to either clang or gcc. This causes it to use /usr/bin/cc or whatever the user has set $(CC) to. This removes the last dependency on gcc for BaseTools. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2023-04-05BaseTools: Allow users to build with clang using CC=clang CXX=clang++Rebecca Cran3-8/+10
In https://bugzilla.tianocore.org/show_bug.cgi?id=2842 clang support was added by having users specify "make CXX=llvm" when building BaseTools. The Makefile then sees that and sets CC=$(CLANG_BIN)clang and CXX=$(CLANG_BIN)clang++. That requires that the executables 'clang' and 'clang++' exist and for example aren't named 'clang-17' and 'clang++-17'. Also, it's an unusual way of specifying the compiler, since many users will expect to be able to override CC and CXX on the make command line. Rework the BaseTools Makefiles removing the 'BUILD_' prefix (BUILD_CC and BUILD_CXX) and using the standard name 'LDFLAGS' instead of 'LFLAGS'. This allows clang to be used by running 'make -C BaseTools CC=clang CXX=clang++'. Signed-off-by: Rebecca Cran <rebecca@quicinc.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2023-04-05BaseTools: Allow users to specify compiler to use with make CC= CXX=Rebecca Cran3-26/+26
In https://bugzilla.tianocore.org/show_bug.cgi?id=2842 clang support was added by having users specify "make CXX=llvm" when building BaseTools. The Makefile then sees that and sets CC=$(CLANG_BIN)clang and CXX=$(CLANG_BIN)clang++. That requires that the executables 'clang' and 'clang++' exist and for example aren't named 'clang-17' and 'clang++-17'. Also, it's an unusual way of specifying the compiler, since many users will expect to be able to override CC and CXX on the make command line. Rework the BaseTools Makefiles removing the 'BUILD_' prefix (BUILD_CC and BUILD_CXX) and using the standard name 'LDFLAGS' instead of 'LFLAGS'. This allows clang to be used by running 'make -C BaseTools CC=clang CXX=clang++'. Signed-off-by: Rebecca Cran <rebecca@quicinc.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2023-04-03BaseTools/VfrCompile: Fix potential buffer overwritesMichael Kubacki2-7/+7
While more portable methods exist to handle these cases, this change does not attempt to do more than fix the immediate problem and follow the conventions already established in this code. `snprintf()` is introduced as the minimum improvement apart from making the buffers larger. Fixes the following CodeQL alerts: 1. Failure on line 2339 in BaseTools/Source/C/VfrCompile/Pccts/antlr/gen.c - Type: Potentially overrunning write - Severity: Critical - Problem: This 'call to sprintf' operation requires 17 bytes but the destination is only 16 bytes. 2. Failure on line 2341 in BaseTools/Source/C/VfrCompile/Pccts/antlr/gen.c - Type: Potentially overrunning write - Severity: Critical - Problem: This 'call to sprintf' operation requires 17 bytes but the destination is only 16 bytes. 3. Failure on line 1309 in BaseTools/Source/C/VfrCompile/Pccts/antlr/main.c - Type: Potentially overrunning write - Severity: Critical - Problem: This 'call to sprintf' operation requires 25 bytes but the destination is only 20 bytes. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
2022-11-08BaseTools/Source/C: Use /Z7 instead of /Zi for host toolsMichael D Kinney4-11/+10
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4139 Update ms.common and *.mak files to use /Z7 instead of /Zi to embed symbol information in obj files for host tools built with VS compilers. This prevents vcxxx.pdb files from being generated in the root of the local edk2 repository or in BaseTools directories. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2022-10-16BaseTools: Remove duplicated words in C toolsPierre Gondois1-2/+2
In an effort to clean the documentation of the above package, remove duplicated words. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
2021-12-09BaseTools/VfrCompile: Correct Bit Field Flags for numeric/one ofHuang, Long12-1/+4
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3752 Add Bit mask to numeric/one of opcode to set correctly Flags for Bit Field. VfrSyntax.g: Set "LFlags &= EDKII_IFR_DISPLAY_BIT" before "LFlags |= (EDKII_IFR_NUMERIC_SIZE_BIT & (_GET_CURRQEST_VARSIZE()));" VfrFormPkg.h: update "if (LFlags & EFI_IFR_DISPLAY)" with "if (LFlags & EDKII_IFR_DISPLAY_BIT)" in SetFlagsForBitField() Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Long1 Huang <long1.huang@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
2021-11-04BaseTools/VrfCompile: Fix uninitialized field from unnamed fieldMichael D Kinney1-2/+2
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3687 If a C structure parsed by the VFR compiler contains an unnamed field, then mFieldName is left uninitialized, which generates random data in the VFR compiler output file. If the FieldName is NULL, then initialize pNewField->mFieldName to a Null-terminated empty string. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2020-11-11BaseTools/VfrCompile: VFR compiler supports REST_STYLE in HII optionAbner Chang1-3/+22
Add REST_STYLE support on VFR language BZ: 2916 https://bugzilla.tianocore.org/show_bug.cgi?id=2916 Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com> Signed-off-by: Ye Ting <ting.ye@intel.com> Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Signed-off-by: Wang Fan <fan.wang@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Nickle Wang <nickle.wang@hpe.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2020-07-21Using LLVM compiler set to build BaseTools in LinuxLiu, Zhiguang3-2/+12
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2842 To use LLVM to build BaseTools, first set the CLANG_BIN environment value, and add "CXX=llvm" to choose LLVM compiler set when using make command. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Yuwei Chen<yuwei.chen@intel.com>
2019-10-04BaseTools: strip trailing whitespaceLeif Lindholm1-3/+3
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
2019-07-08BaseTools: Fix various typosAntoine Cœur2-2/+2
Fix various typos in BaseTools. Signed-off-by: Cœur <coeur@gmx.fr> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2019-05-13BaseTools/VfrCompile: clean Framework Vfr supportDandan Bi1-217/+55
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1464 This commit is to do the cleanup which are missing in previous commit 1b72fd5121b5b31918be0a9a0868a39070d4c8d4 BaseTools/VfrCompile: Remove framework VFR support Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2019-05-09BaseTools/VfrCompile: Remove framework VFR supportDandan Bi7-211/+15
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1464 Currently there is no usage of framework VFR, remove the support from VfrCompile. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2019-04-09BaseTools: Replace BSD License with BSD+Patent LicenseMichael D Kinney12-84/+12
https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2019-02-14BaseTools: Various typoAntoine Coeur28-102/+97
Various typo in BaseTools. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Coeur <coeur@gmx.fr> Reviewed-by: Liming Gao <liming.gao@intel.com>
2019-01-08BaseTools/VfrCompile: report error for Integer overflowDandan Bi3-7/+7
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1415 When an integer constant specified in the .vfr file is too large for the varstore field it is being used with, the VFR compiler reports an overflow warning like this: Test.vfr(693): WARNING: Overflow: Value 1024 is too large to store in a UINT8 : String to UINT* Overflow Since Warning does not break the build process, and it is easy to miss it. This patch is to update the code to report error and break the build if meet this kind of issue. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2018-08-22BaseTools/VfrCompile: honor EXTRA_LDFLAGSLaszlo Ersek1-1/+4
In commit 81502cee20ac ("BaseTools/Source/C: take EXTRA_LDFLAGS from the caller", 2018-08-16), I missed that "VfrCompile/GNUmakefile" does not use BUILD_LFLAGS in the APPLICATION linking rule, unlike "app.makefile" does. Instead, "VfrCompile/GNUmakefile" uses the (undefined) LFLAGS macro. Therefore commit 81502cee20ac did not cover the linking step of VfrCompile. Thankfully, the structure of the linking rules is the same, between "app.makefile" and "VfrCompile/GNUmakefile". Rename the undefined LFLAGS macro in "VfrCompile/GNUmakefile" to VFR_LFLAGS (for consistency with VFR_CXXFLAGS), and set it to EXTRA_LDFLAGS. As a result, we have: | compilation | linking -----------+--------------------------------+---------------------- VfrCompile | VFR_CXXFLAGS = | VFR_LFLAGS = | BUILD_OPTFLAGS = | EXTRA_LDFLAGS | '-O2' + EXTRA_OPTFLAGS | -----------+--------------------------------+---------------------- other apps | BUILD_CFLAGS/BUILD_CXXFLAGS = | BUILD_LFLAGS = | [...] + BUILD_OPTFLAGS = | [...] + EXTRA_LDFLAGS | [...] + '-O2' + EXTRA_OPTFLAGS | This table shows - that the VfrCompile compilation and linking flags are always a subset of the corresponding flags used by the other apps, - and that the EXTRA flags are always at the end. Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1540244 Fixes: 81502cee20ac4046f08bb4aec754c7091c8808dc Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2018-08-16BaseTools/Source/C: split "-O2" to BUILD_OPTFLAGSLaszlo Ersek1-4/+7
The option "-O2" is not a preprocessor flag, but a code generation (compilation) flag. Move it from BUILD_CPPFLAGS to BUILD_CFLAGS and BUILD_CXXFLAGS. Because "VfrCompile/GNUmakefile" uses "-O2" through BUILD_CPPFLAGS, and because it doesn't use BUILD_CXXFLAGS, we have to introduce BUILD_OPTFLAGS separately, so that "VfrCompile/GNUmakefile" can continue using just this flag. This patch doesn't change behavior. Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1540244 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2018-07-09BaseTools: Clean up source filesLiming Gao9-226/+226
1. Do not use tab characters 2. No trailing white space in one line 3. All files must end with CRLF Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
2018-05-09BaseTools/VfrCompile: Avoid using uninitialized pointerBi, Dandan1-3/+20
V2: Add function _INIT_OPHDR_COND () for variable initialization. Make code logic more clean. Previously _CLEAR_SAVED_OPHDR () is used for variable initialization, and we updated it to clean memory. But _CLEAR_SAVED_OPHDR () is still called for variable initialization. This will cause uninitialized pointer will be checked to free and cause unexpected issue. This patch is to add new function for variable initialization and keep _CLEAR_SAVED_OPHDR () to clean memory which is aligned with its function name. Cc: Liming Gao <liming.gao@intel.com> Cc: Gary Lin <glin@suse.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
2018-04-17BaseTool/VfrCompile: make delete[] match with new[]Dandan Bi1-4/+8
Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
2018-04-17BaseTools/VfrCompile:Fix memory leak issuesDandan Bi1-1/+31
Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
2018-03-23BaseTool/VfrCompile: Fix potential memory leak issueBi, Dandan1-0/+4
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=771 Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2018-03-23BaseTool/VfrCompile: make delete[] match with new[]Bi, Dandan5-22/+22
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=764 Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2018-02-06BaseTools GNUmakefile: Remove HOST_ARCH in every tool MakefileLiming Gao1-2/+1
HOST_ARCH has been moved into the common header.makefile Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com>
2018-01-02BaseTools: resolve initialization order errors in VfrFormPkg.hzenith4323-414/+257
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>
2018-01-02BaseTools: silence parentheses-equality warningzenith4324-1/+7
Some code generated by antlr causes clang to emit warning warning: equality comparison with extraneous parentheses [-Wparentheses-equality] The warning is suppressed specifically for clang without affecting other compilers. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Zenith432 <zenith432@users.sourceforge.net> Reviewed-by: Liming Gao <liming.gao@intel.com>
2018-01-02BaseTools: eliminate unused expression resultzenith4322-3/+3
Remove some code generated by antlr that causes clang to emit warning warning: expression result unused [-Wunused-value] Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Zenith432 <zenith432@users.sourceforge.net> Reviewed-by: Liming Gao <liming.gao@intel.com>
2018-01-02BaseTools: correct mal-typed CVfrDLGLexer::errstdzenith4321-1/+1
The member function CVfrDLGLexer::errstd is intended as an override virtual function of DLGLexerBase::errstd, but due to mismatched prototype, it didn't override, and never got called. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Zenith432 <zenith432@users.sourceforge.net> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-12-25BaseTools/VfrCompile: Resolve uninit class variables in constructorHao Wu3-0/+10
The commit initializes those possibly uninitialized class variables in class constructors. Cc: Yonghong Zhu <yonghong.zhu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-12-25BaseTools/VfrCompile: Add/refine boundary checks for strcpy/strcatHao Wu1-4/+10
Add checks to ensure when the destination string buffer is of fixed size, the strcpy/strcat functions calls will not access beyond the boundary. Cc: Yonghong Zhu <yonghong.zhu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-12-25BaseTools/VfrCompile: Assign 'NULL' for closed file handleHao Wu1-1/+2
Assign 'NULL' value to the already-closed file handle to avoid closing the handle multiple times. Cc: Yonghong Zhu <yonghong.zhu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-11-30BaseTools: Replace ARCH with HOST_ARCH in C Makefile to avoid conflictLiming Gao1-1/+1
https://bugzilla.tianocore.org/show_bug.cgi?id=793 ARCH is too generic. It may cause confuse of target arch or host arch. To be clarified, replace it with HOST_ARCH in BaseTools C Makefile. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
2017-11-03BaseTools/VfrCompile: Add check to avoid using NULL pointerDandan Bi1-2/+6
Question value are stored in one specified storage, but the Data type of the storage is not specified or there is no sub fields in the Data type sometimes, so we need to add check before using related pointers. Here list some NULL cases: (1)For an efivastore which doesn't specify a data structure or a data type(UINT8,UINT16...)as the storage, just has VarName and VarSize instead, we can not get its data type before parsing its VarSize. (2)For efivastore which just specifies the data type(UINT8,UINT16...) not a structure as the storage,this data type doesn't have sub-fields. Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-09-21BaseTool/VfrCompiler: Support Bit fields in EFI/Buffer VarStoreDandan Bi7-489/+1177
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=545 Enhance VfrCompiler to parse following case: 1. EFI/Buffer VarStore can contain bit fields in their structure. 2. For question Oneof/Checkbox/numeric, their storage can be bit fields of an EFI VarStore/Buffer VarStore. Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-09-21BaseTool/VfrCompile: Support Union type in VFRDandan Bi3-37/+65
https://bugzilla.tianocore.org/show_bug.cgi?id=603 Update VfrCompiler to parse the UNION type in vfr file Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@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: Liming Gao <liming.gao@intel.com>
2017-08-04BaseTools/VfrCompile: Remove the MAX_PATH limitationDandan Bi2-26/+1
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=579 Since we have already used LongFilePath() to convert file path, so we can remove the MAX_PATH limitation. Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Daniel Díaz <daniel.diaz@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
2017-08-04BaseTools/VfrCompile: Fix segmentation fault issuesDandan Bi1-7/+7
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=532 (1) Add NULL check before using a pointer. (2) Use "%s" format string in DebugError function to avoid crash caused by incorrect input. Cc: Bo Chen <chenbo@pdx.edu> Cc: Liming Gao <liming.gao@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>
2017-02-22VfrCompile: fix invalid comparison between pointer and integerPaolo Bonzini1-1/+1
This would be valid C but is not valid C++, so change the comparison to do what it has always been doing. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
2017-01-23BaseTools: Convert incomplete expression with dangling while()Nikolai SAOUKH1-3/+3
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Nikolai SAOUKH <nms@otdel-1.org> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-12-23BaseTools/Pccts: Resolve GCC sting format mismatch build warningHao Wu1-1/+1
https://bugzilla.tianocore.org/show_bug.cgi?id=282 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-12-20BaseTools: fix write-strings build warningsHeyi Guo1-1/+1
Fix build warnings of "deprecated conversion from string constant to ?CHAR8* {aka char*}? [-Wwrite-strings]" for BaseTools, while using "gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)". Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-12-20BaseTools: fix format type build warningsHeyi Guo2-10/+10
Fix build warnings of "format ?%d? expects argument of type ?int?, but argument 5 has type ?long unsigned int? [-Wformat=]" for BaseTools, while using "gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)". Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-12-20BaseTools: fix format-security build warningsHeyi Guo3-6/+6
Fix build warnings of "format not a string literal and no format arguments [-Wformat-security]" for BaseTools, while using "gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3)". Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>