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>
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>
GNU make built-in rule to Compiling C++ programs with
‘$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c’.
To align to it, add empty BUILD_CXXFLAGS in cpp rule.
Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
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: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
On FreeBSD, uuid.h is in /usr/include, not /usr/include/uuid.
Fix some errors when building using clang caused by self-assignment: the
preferred way to 'use' a variable is '(void)x;', not 'x = x;'.
Where the system provides $(CC) etc. by default, don't override it to be gcc.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bruce Cran <bruce@cran.org.uk>
Reviewed-by: Yingke Liu <yingke.d.liu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17866 6f19259b-4bc3-4df7-8a09-765794883524
Support for building BaseTools on AArch64 is available in the tree, but
not currently "plugged in". This patch adds the required snippet.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16169 6f19259b-4bc3-4df7-8a09-765794883524
-fno-merge-constants is not supported by clang, and it warns it will turn into
a hard error in the future.
-Wno-deprecated-declarations removes warnings about obsolete libraries that
are not secure.
-Wno-self-assign removes warnings from LZMA code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anderw Fish <afish@apple.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15938 6f19259b-4bc3-4df7-8a09-765794883524
Michael D Kinney
Chao Li
fengyunhua
gaoliming
Nikita
Liu, Zhiguang
Park, Aiden
Leif Lindholm
Antoine Cœur
Rebecca Cran
Feng, Bob C
Fan, ZhijuX
Dongao Guo
Laszlo Ersek
Liming Gao
Chema Gonzalez
Hao Wu
Bruce Cran
Andrew Fish
Yingke Liu
lgao4