BaseTools has been duplicating and adapting code that is defined in
MdePkg and MdeModulePkg. This leads to desync issues where the same
symbols may be backed by different functions with slightly different
semantics and also fixes that apply only to BaseTools or only to MdePkg
and MdeModulePkg.
To address these issues, update BaseTools/Source/C to utilize the code
from MdePkg and MdeModulePkg.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Use the MdePkg version instead of maintaining a copy in BaseTools.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Use the MdePkg version instead of maintaining a copy in BaseTools.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
threading.currentThread is a deprecated alias for
threading.current_thread, and causes a warning to be displayed when it's
called. Update NmakeSubdirs.py to use the latter method instead.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
clang 17 defaults to C++17, where the 'register' keyword is deprecated
and the warning changed to an error. To avoid build errors, compile
against C++14 by specifying '-std=c++14' in CXXFLAGS.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
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>
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>
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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4053
C code changes for building EDK2 LoongArch platform.
For definitions of PE/COFF and LOONGARCH relocation types, see the
"Machine Types" and "Basic Relocation Types" sections of this URL for
LOONGARCH values:
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
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: Chao Li <lichao@loongson.cn>
Co-authored-by: Dongyan Qian <qiandongyan@loongson.cn>
Co-authored-by: Baoqi Zhang <zhangbaoqi@loongson.cn>
Co-authored-by: Yang Zhou <zhouyang@loongson.cn>
Co-authored-by: Xiaotian Wu <wuxiaotian@loongson.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
On windows system, when use command chcp displays the number of the
active console code page, if the active console code is 936, run
make cleanall in the BaseTools will hang.
Issue reproduce step:
chcp 936
edksetup.bat VS2015
cd BaseTools
nmake cleanall
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: Yunhua Feng <fengyunhua@byosoft.com.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2938
C tool may add the additional INC include path. They should have
high priority than the common INC include path.
This fix is to resolve the structure PCD issue to refer to the same
header file defined in BaseTools and MdePkg. The one in MdePkg should
be used.
Cc: Yuwei Chen <yuwei.chen@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Yuwei Chen<yuwei.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Tested-by: Garrett Kirkendall <garrett.kirkendall@amd.com>
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>
This issue happens under two conditions.
1. Unicode language environment in Windows
2. Python2 (Not reproducible with Python3)
Step to reproduce
C:\edk2>edksetup.bat forcerebuild
The edksetup.bat stuck at 'nmake cleanall'.
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Some systems such as FreeBSD identify the platform as 'arm64'
and not 'aarch64' as Linux does.
Signed-off-by: Rebecca Cran <rebecca@bluestop.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: fix up DKIM damage in the "From:" address]
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1764
Some compiler flags restrict the compiler from making
arbitrary decisions while handling undefined C/C++ behaviors.
Therefore they can be used to fix some issues caused by undefined behavior.
For example, for GCC, the following flags are available:
-fno-delete-null-pointer-checks tells
the compiler NOT to assume that null pointer deference does not exist.
-fwrapv tells the compiler that signed overflow always wraps.
This patch is going to add these 2 build options to
BaseTool GCC build option.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1764
To be easy to review in future, split the long line into
multiple shorter lines.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1670
During BaseTools compiling under Chinese or Japanese
language Windows, python exception occurring.
UnicodeDecodeError: 'ascii' codec can't decode byte 0xbd
in position 3528: ordinal not in range(128)
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: Zhiju.Fan <zhijux.fan@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Add NmakeSubdirs.py to replace NmakeSubdirs.bat in VS Makefile. This script will
invoke nmake in multi thread mode. It can save more than half time of BaseTools
C clean build.
GCC make supports multiple thread in make phase. So, GNUmakefile doesn't need apply
this script.
single task or job=1:
just single thread and invoke subprocess,subprocess will use
system.stdout to print output.
multi task:
thread number is logic cpu count.All subprocess output will pass to
python script by PIPE and then script print it to system.stdout.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dongao Guo<dongao.guo@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Test-by: Liming Gao <liming.gao@intel.com>
Allow the caller of the top-level makefile either to set EXTRA_LDFLAGS in
the environment or to pass EXTRA_LDFLAGS as a macro definition on the
command line. EXTRA_LDFLAGS extends (and potentially overrides) default
link-editing flags set in the makefiles.
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>
Allow the caller of the top-level makefile either to set EXTRA_OPTFLAGS in
the environment or to pass EXTRA_OPTFLAGS as a macro definition on the
command line. EXTRA_OPTFLAGS extends (and potentially overrides) default C
compilation flags set in the makefiles.
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>
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>
Option "-c" is a mode selection flag (choosing between compiling and
linking); it should not be in BUILD_CFLAGS, which applies only to
compiling anyway. The compilation rule for C source files, in
"footer.makefile", already includes "-c" -- currently we have double "-c"
options.
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>
BUILD_CPPFLAGS should be expanded before BUILD_CFLAGS. (The rule for C++
source files already does this, with BUILD_CPPFLAGS and BUILD_CXXFLAGS.)
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>
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>
I recently added the gcc-8 specific "-Wno-stringop-truncation" and
"-Wno-restrict" options to BUILD_CFLAGS, both for "Darwin" (XCODE5 /
clang, OSX) and otherwise (gcc, Linux / Cygwin).
I also regression-tested the change with gcc-4.8 on Linux -- gcc-4.8 does
not know either of the (gcc-8 specific) "-Wno-stringop-truncation" and
"-Wno-restrict" options, yet the build completed fine (by GCC design).
Regarding OSX, my expectation was that
- XCODE5 / clang would either recognize these warnings options (because
clang does recognize most -W options of gcc),
- or, similarly to gcc, clang would simply ignore the "-Wno-xxx" flags
that it didn't recognize.
Neither is the case; the new flags have broken the BaseTools build on OSX.
Revert them (for OSX only).
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Reported-by: Liming Gao <liming.gao@intel.com>
Fixes: 1d212a83df0eaf32a6f5d4159beb2d77832e0231
Fixes: 9222154ae7b3eef75ae88cdb56158256227cb929
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
gcc-8 (which is part of Fedora 28) enables the new warning
"-Wrestrict" in "-Wall". This warning is documented in detail
at <https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html>; the
introduction says
> Warn when an object referenced by a restrict-qualified parameter (or, in
> C++, a __restrict-qualified parameter) is aliased by another argument,
> or when copies between such objects overlap.
It breaks the BaseTools build (in the Brotli compression library) with:
> In function 'ProcessCommandsInternal',
> inlined from 'ProcessCommands' at dec/decode.c:1828:10:
> dec/decode.c:1781:9: error: 'memcpy' accessing between 17 and 2147483631
> bytes at offsets 16 and 16 overlaps between 17 and 2147483631 bytes at
> offset 16 [-Werror=restrict]
> memcpy(copy_dst + 16, copy_src + 16, (size_t)(i - 16));
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In function 'ProcessCommandsInternal',
> inlined from 'SafeProcessCommands' at dec/decode.c:1833:10:
> dec/decode.c:1781:9: error: 'memcpy' accessing between 17 and 2147483631
> bytes at offsets 16 and 16 overlaps between 17 and 2147483631 bytes at
> offset 16 [-Werror=restrict]
> memcpy(copy_dst + 16, copy_src + 16, (size_t)(i - 16));
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Paolo Bonzini <pbonzini@redhat.com> analyzed the Brotli source in detail,
and concluded that the warning is a false positive:
> This seems safe to me, because it's preceded by:
>
> uint8_t* copy_dst = &s->ringbuffer[pos];
> uint8_t* copy_src = &s->ringbuffer[src_start];
> int dst_end = pos + i;
> int src_end = src_start + i;
> if (src_end > pos && dst_end > src_start) {
> /* Regions intersect. */
> goto CommandPostWrapCopy;
> }
>
> If [src_start, src_start + i) and [pos, pos + i) don't intersect, then
> neither do [src_start + 16, src_start + i) and [pos + 16, pos + i).
>
> The if seems okay:
>
> (src_start + i > pos && pos + i > src_start)
>
> which can be rewritten to:
>
> (pos < src_start + i && src_start < pos + i)
>
> Then the numbers are in one of these two orders:
>
> pos <= src_start < pos + i <= src_start + i
> src_start <= pos < src_start + i <= pos + i
>
> These two would be allowed by the "if", but they can only happen if pos
> == src_start so they degenerate to the same two orders above:
>
> pos <= src_start < src_start + i <= pos + i
> src_start <= pos < pos + i <= src_start + i
>
> So it is a false positive in GCC.
Disable the warning for now.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Cole Robinson <crobinso@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Reported-by: Cole Robinson <crobinso@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
gcc-8 (which is part of Fedora 28) enables the new warning
"-Wstringop-truncation" in "-Wall". This warning is documented in detail
at <https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html>; the
introduction says
> Warn for calls to bounded string manipulation functions such as strncat,
> strncpy, and stpncpy that may either truncate the copied string or leave
> the destination unchanged.
It breaks the BaseTools build with:
> EfiUtilityMsgs.c: In function 'PrintMessage':
> EfiUtilityMsgs.c:484:9: error: 'strncat' output may be truncated copying
> between 0 and 511 bytes from a string of length 511
> [-Werror=stringop-truncation]
> strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> EfiUtilityMsgs.c:469:9: error: 'strncat' output may be truncated copying
> between 0 and 511 bytes from a string of length 511
> [-Werror=stringop-truncation]
> strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> EfiUtilityMsgs.c:511:5: error: 'strncat' output may be truncated copying
> between 0 and 511 bytes from a string of length 511
> [-Werror=stringop-truncation]
> strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The right way to fix the warning would be to implement string concat with
snprintf(). However, Microsoft does not appear to support snprintf()
before VS2015
<https://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010>,
so we just have to shut up the warning. The strncat() calls flagged above
are valid BTW.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Cole Robinson <crobinso@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
With this change, enter single tool directory, make can pass.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
I was getting `HOST_ARCH` set using the linux arch name ("x86_64"), which
is different from the MS one ("X64").
It is not clear anyway we can proceed without valid build variables
(`ARCH_INCLUDE`, `BIN_PATH`, `LIB_PATH`, `SYS_BIN_PATH`, and
`SYS_LIB_PATH`).
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chema Gonzalez <chemag@gmail.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
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>
In batch script file NmakeSubdirs.bat, the value changes made to the
variable 'TOOL_ERROR' within the 'setlocal...endlocal' block will not be
reflected in the return value of the script. A value of 0 will always be
returned. Thus, the script will not reflect the result of the 'nmake'
command correctly when building BaseTool source codes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
This warning has been disabled for C file. To be same, it is also disabled
for CPP file.
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>
/MD option will introduce the specific version dll dependency. It will cause
the compiled C tools not work on some system.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
ms.common is included by every tool Makefile. it is not necessary to be placed
in ms.app again.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
