Certain environments require Control Flow Guard (CFG) to be enabled at
build time as part of their security hardening requirements.
This change adds the necessary compiler and linker flags to enable CFG
support.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
Add conditional suppression of MSVC warning C4028 (formal parameter
different from declaration) when building with Visual Studio 2017 or
earlier toolchain.
This warning is triggered by brotli submodule and not emitted by newer
compilers, hence a conditional supression is used.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This reverts commit 3fe1d56cc9.
PR https://github.com/tianocore/edk2/pull/11757 introduced a
"Breaking Change" feature for out of tree builds of tools.
This breaking change is blocking testing of edk2-stable202602
due to side effects on building FitGen tool in edk2-platforms.
Revert this feature for the edk2-stable202602 release and
work on this feature after the release.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
This reverts commit f0542ae07d.
PR https://github.com/tianocore/edk2/pull/11757 introduced a
"Breaking Change" feature for out of tree builds of tools.
This breaking change is blocking testing of edk2-stable202602
due to side effects on building FitGen tool in edk2-platforms.
Revert this feature for the edk2-stable202602 release and
work on this feature after the release.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Use $(SEP) with addprefix of $(OBJDIR) to support Windows MINGW
CLANG builds that use Windows path separators with GNU makefiles.
This fixes Windows MINGW CLANG builds of the PcdValueInit
application that is required for structured PCDs.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Main EDK2 build supports out-of-tree builds but BaseTools make process
still creates tools and object files in-tree. In order to make
out-of-tree build support complete move the generated tools and
interim obj files to $WORKSPACE location as well.
This patch also changes the location of BaseTools for in-tree builds
(default behavior when WORKSPACE is not provided before calling
edksetup) to $WORKSPACE/BaseTools/Build/... It may potentially break
external workflows that invoke tools from the default location outside
of the build tool.
Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
Update _get_win32_parent_processes() to detect a
cycle in parent process ids that can cause
_get_win32_parent_processes() to never return.
If a pid cycle is detected, then return the list
of parent process ids detected up to the point
the cycle is detected.
GitHub Actions builds using windows-2025 can
reproduce this issue once in a while. It shows
up as job that runs until a timeout. If the job
is canceled, the logs show a python stack in the
loop in _get_win32_parent_processes().
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Use $(OS) in all GNUMakefiles to detect if the GNUMakefile
is being used in a Windows OS. If a Windows OS is detected,
then override SHELL to use cmd.exe. This prevents make
utility from using sh.exe if sh.exe happens to be in PATH.
If sh.exe is used, then backslash (\) characters in file
paths are removed and builds break for files not found.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Add newlines to the error messages in GnuMakeUtils. writelines function
does not add newlines automatically so the print is merged with a line
that is printed next.
Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
Building the C BaseTools using Clang on a Windows system that has the Python
interpreter installed to a path that contains spaces (for example
C:\Program Files\Python314\python.exe) currently fails.
This change adds quoting to fix that issue.
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
edk2 is dropping support for the ARM32 architecture. This
commit removes ARM32 code from BaseTools.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
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>
Add /wd4200 to all visual studio builds of C tools in BaseTools.
This disables warnings for use of flexible array members that
are allowed in edk2 include files. Some tools use include files
from MdePkg that use flexible array members.
This matches the warning disables used to build structured PCD in
BaseTools/Source/Python/Workspace/DscBuildData.py where flexible
array members are more widely used.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
This change added the build script to cross compile the base tool
binaries for Linux ARM/AARCH64 systems.
The needed libuuid system library is pulled from source file and rebuilt
to support the corresponding library dependencies. Individual tools'
makefiles are also updated to link the cross compiled library as well.
The EDK2 base tool build script was also updated to support such change.
This was tested functional on Linux ARM host system.
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>
This change focuses on the support of building basetool natively for
Windows ARM/ARM64 host system, which will enable the ARM based platforms
to build UEFI and unit tests.
Note that the warnings due to integer conversions are suppressed for
this specific target to avoid too much local changes carried in MU. The
formal change should drop all these binaries and move to pythonic
scripts.
The 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>
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: 1d212a83df
Fixes: 9222154ae7
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>
