FCE is a tool to retrieve and change HII configuration data in
Firmware Device(*.fd) files.
https://bugzilla.tianocore.org/show_bug.cgi?id=1848
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1464
This commit is to do the cleanup which are missing in
previous commit 1b72fd5121
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>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1789
If the input file is not a valid file, it may cause dead loop,
because the return of fread function is not checked.
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
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>
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>
Sync SECTION_SIZE() from MdePkg to BaseTools, from an earlier patch in
this series.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1450
In the Multiple thread Genfds feature, build tool generates
GenSec, GenFFS command in Makefile.
The Non-Hii Driver does not generate .offset file for uni string offset,
but the build tool has not knowledge about this in autogen phase. So
in this patch, I add a check in Makefile for GenSec command. If the GenSec
input file does not exist, the GenSec will not be called. And if GenSec
command is not called, its output file, which is also the input file of
GenFfs command, will also not exist.So for GenFfs command,
I add a new command parameter -oi which means
the input file is an optional input file which would not exist. so
that I can generate GenFfs command with "-oi" parameter in Makefile.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.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>
The boundary validation checking in MakeTable() performs on
every loop iteration. This could be improved by checking
just once before the loop.
https://bugzilla.tianocore.org/show_bug.cgi?id=1329
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The boundary validation checking in MakeTable() performs on
every loop iteration. This could be improved by checking
just once before the loop.
https://bugzilla.tianocore.org/show_bug.cgi?id=1329
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1622
There is duplicated $(PYTHON_COMMAND) in the
command of cleanall
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
If the input parameter AsciiString length is greater
than 255, the GenFv will hang.
This patch is to fix this issue.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
XCODE5 reports warning "equality comparison with extraneous parentheses".
Remove extraneous parentheses around the comparison to silence this warning.
This issue is caused by commit 8daa4278e8.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Feng Bob C <bob.c.feng@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
Warning message is that "equality comparison with extraneous parentheses"
Remove extraneous parentheses around the comparison to silence this warning.
This issue is caused by commit 8daa4278e8.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Feng Bob C <bob.c.feng@intel.com>
Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1423
There is usage model that SecCore and PeiCore are in different FVs.
Update BaseTools to support this usage model.
Test: Verified on internal platform with the case SecCore and
PeiCore in different FVs and built/booted successfully.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
We currently permit R_ARM_GOT_PREL relocations in the ELF32 conversion
routines, under the assumption that relative relocations are fine as
long as the section layout is the same between ELF and PE/COFF.
However, as is the case with any proxy generating relocation, it is
up to the linker to emit an entry in the GOT table and populate it
with the correct absolute address, which should also be fixed up at
PE/COFF load time. Unfortunately, the relocations covering the GOT
section are not emitted into the static relocation sections processed
by GenFw, but only in the dynamic relocation section as a R_ARM_RELATIVE
relocation, and so GenFw fails to emit the correct PE/COFF relocation
data for GOT entries.
Since GOT indirection is pointless anyway for PE/COFF modules running
in UEFI context, let's just drop the references to R_ARM_GOT_PREL from
GenFw, resulting in a build time failure rather than a runtime failure
if such relocations do occur.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The macro MAX_ADDRESS represents the largest virtual address that
is valid for a certain architecture. For the BaseTools, this quantity
is irrelevant, since the same tools can be used to build for different
targets.
Since we only refer to it in a single place, which is an ASSERT() that
doesn't seem particularly useful (it ensures that memcpy() will not
be called with arguments that will make it read beyond the end of the
address space and wrap around), let's drop the ASSERT and all references
to MAX_ADDRESS.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Given that DuetPkg will be removed, tools only used by
DuetPkg can also be removed after its removal operation.
https://bugzilla.tianocore.org/show_bug.cgi?id=1322
v2:Remove these tools in Makefile and GNUmakefile.
v4:Remove these tools in BinWrappers/PosixLike/ and
UserManuals.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The maximum value that can be represented by the native word size
of the *target* should be irrelevant when compiling tools that
run on the build *host*. So drop the definition of MAX_UINTN, now
that we no longer use it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Parsing a string into an integer variable of the native word size
is not defined for the BaseTools, since the same tools may be used
to build firmware for different targets with different native word
sizes.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Replace the default size limit of IsDevicePathValid() with a value
that does not depend on the native word size of the build host.
4 GiB seems sufficient as the upper bound of a device path handled
by UEFI.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Since we will be dropping the definition of MAX_UINTN, whose meaning
is ambiguous for the BaseTools, add a definition of MAX_UINT32 that
we can switch to.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Replace invocations of StrHexToUintn() with StrHexToUint64(), so
that we can drop the former.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Don't use the native word size string to number parsing routines,
but instead, use the 64-bit one and cast to UINTN.
Currently, the only user is in Source/C/DevicePath/DevicePathFromText.c
which takes care to use Strtoi64 () unless it assumes the value fits
in 32-bit, so this change is a no-op even on 32-bit build hosts.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
In the context of the BaseTools, there is no such thing as a native word
size, given that the same set of tools may be used to build a firmware
image consisting of both 32-bit and 64-bit modules.
So update StrToIpv4Address() and StrToIpv6Address() to use UINT64
types instead of UINTN types when parsing strings.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
GenVtf C tool is IPF specific. IPF support has been removed
from edk2 trunk. This tool can be removed.
https://bugzilla.tianocore.org/show_bug.cgi?id=1349
v2:Remove GenVtf in Makefile and GNUmakefile.
v3:Remove BinWrappers/PosixLike/GenVtf and the user manual
of GenVtf.
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1317
This is a regression issue caused by 041d89bc0f.
In Decode() function, once mOutBuf is fully filled, Decode() should return.
Current logic misses the checker of mOutBuf after while() loop.
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>
V3:
Update the error message for array checker.
V2:
1. Add comments for each ASSERT.
2. ASSERT need to skip the case of array size of array as zero. For
example, TestArray[] in struct in header file.
V1:
For structure PCD,
1. use compiler time assert to check the array index, report error
if array index exceeds the array number.
2. use compiler time assert to check the array size, report error
if the user declared size in header file is smaller than the user
defined in DEC/DSC file.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: ZhiqiangX Zhao <zhiqiangx.zhao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Add one new option --uefi to enable UefiCompress.
(re-add this patch since it be reverted in Python3 migration patches,
but this patch is not related with Python3)
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng <yunhuax.feng@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
the PyUtility is not used, so we remove it.
(re-add this patch since it be reverted in Python3 migration patches,
but this check is not related with Python3)
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
This reverts commit 6693f359b3c213513c5096a06c6f67244a44dc52..
678f851312.
Python3 migration is the fundamental change. It requires every developer
to install Python3. Before this migration, the well communication and wide
verification must be done. But now, most people is not aware of this change,
and not try it. So, Python3 migration is reverted and be moved to edk2-staging
Python3 branch for the edk2 user evaluation.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
the PyUtility is not used, so we remove it.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@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>
In commit 81502cee20 ("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 81502cee20 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: 81502cee20
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_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>
Adds support for the following X64 ELF relocations to GenFw
R_X86_64_GOTPCREL
R_X86_64_GOTPCRELX
R_X86_64_REX_GOTPCRELX
Background:
The GCC49 and GCC5 toolchains use the small pie model for X64. In the
small pie model, gcc emits a GOTPCREL relocation whenever C code takes
the address of a global function. The emission of GOTPCREL is mitigated
by several factors
1. In GCC49, all global symbols are declared hidden thereby eliminating
the emission of GOTPCREL.
2. In GCC5, LTO is used. In LTO, the complier first creates intermediate
representation (IR) files. During the static link stage, the LTO compiler
combines all IR files as a single compilation unit, using linker symbol
assistance to generate code. Any global symbols defined in the IR that
are not referenced from outside the IR are converted to local symbols -
thereby eliminating the emission of GOTPCREL for them.
3. The linker (binutils ld) further transforms any GOTPCREL used with
the movq opcode to a direct rip-relative relocation used with the leaq
opcode. This linker optimization can be disabled with the option
-Wl,--no-relax. Furthermore, gcc is able to emit GOTPCREL with other
opcodes
- pushq opcode for passing arguments to functions.
- addq/subq opcodes for pointer arithmetic.
These other opcode uses are not transformed by the linker.
Ultimately, in GCC5 there are some emissions of GOTPCREL that survive
all these mitigations - if C code takes the address of a global function
defined in assembly code - and performs pointer arithmetic on the
address - then the GOTPCREL remains in the final linker product.
A GOTPCREL relocation today causes the build to stop since GenFw does
not handle them. It is possible to eliminate any remaining GOTPCREL
emissions by manually declaring the global symbols causing them to have
hidden visibility. This patch is offered instead to allow GenFw to
handle any residual GOTPCREL.
Cc: Shi Steven <steven.shi@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zenith432 <zenith432@users.sourceforge.net>
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>
Add support for the following types to VolInfo:
EFI_FV_FILETYPE_MM_STANDALONE
EFI_FV_FILETYPE_MM_CORE_STANDALONE
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ezra Godfrey <egodfrey.qdt@qualcommdatacenter.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
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>
Issue:
genfds-multi-thread create makefile before section file generation,
so it get alignment is zero from empty file. It is incorrect.
solution:
GenSec get section alignment from input file when the input alignment
is zero.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng <yunhuax.feng@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
"-Wstringop-overflow" 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 string manipulation functions such as memcpy and
> strcpy that are determined to overflow the destination buffer.
It breaks the BaseTools build with:
> GenVtf.c: In function 'ConvertVersionInfo':
> GenVtf.c:132:7: error: 'strncpy' specified bound depends on the length
> of the source argument [-Werror=stringop-overflow=]
> strncpy (TemStr + 4 - Length, Str, Length);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> GenVtf.c:130:14: note: length computed here
> Length = strlen(Str);
> ^~~~~~~~~~~
It is a false positive because, while the bound equals the length of the
source argument, the destination pointer is moved back towards the
beginning of the destination buffer by the same amount (and this amount is
range-checked first, so we can't precede the start of the dest buffer).
Replace both strncpy() calls with memcpy().
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
"-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>
Per UEFI spec, FibreEx.WWN, FibreEx.Lun, SasEx.Address, SasEx.Lun
and iSCSI.Lun are all 8-byte array with byte #0 in the left.
It means "0102030405060708" should be converted to:
UINT8[8] = {01, 02, 03, 04, 05, 06, 07, 08}
or UINT64 = {0807060504030201}
Today's implementation wrongly uses the reversed order.
The patch fixes this issue by using StrHexToBytes().
Copy this solution from MdePkg Hash version d0196be.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
If protocol string is not specified, default TCP(0) should be used.
Today's implementation wrongly sets to 1 for this case.
Copy the fix solution from MdePkg Hash version e6c80aea.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
DebugEntry FileOffset is required to be updated to the virtual address if
the input image is converted to XIP image.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
New GUID definition is conflicted with GUID in Windows Kits guiddef.h.
GUID definition will be defined when it is undefined.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
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>
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>
VS2010 also defined RSIZE_MAX, so we undef it first.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Currently "BaseTools/Source/C/DevicePath/DevicePath.c" fails to build with
GCC48:
> DevicePath.c: In function 'print_mem':
> DevicePath.c:109:5: error: 'for' loop initial declarations are only
> allowed in C99 mode
> for (size_t i=0; i<n; i++) {
> ^
> DevicePath.c:109:5: note: use option -std=c99 or -std=gnu99 to compile
> your code
In addition, the print_mem() function does not conform to the edk2 coding
style:
- we use CamelCase and no underscores in identifiers,
- the types and type qualifiers should follow the edk2 style,
- initialization as part of definition is forbidden for local variables.
Clean these up.
While updating the print_mem()/PrintMem() call sites, also remove the
superfluous parentheses around the second argument.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Fixes: 7dbc50bd24
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
UINT64 is defined as the different type for the different ARCHs. To
let it work for all archs and compilers, add (unsigned long long) for
the input value together with %llx.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
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>
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>
Shenglei Zhang
Dandan Bi
Liu, Zhiguang
Rebecca Cran
Feng, Bob C
Laszlo Ersek
Michael D Kinney
Fan, ZhijuX
Antoine Coeur
Liming Gao
Mike Turner
Chasel, Chiu
Ard Biesheuvel
Feng, YunhuaX
Zhaozh1x
Yonghong Zhu
Dongao Guo
Zenith432
Ezra Godfrey
Feng, YunhuaX
Chema Gonzalez
Hao Wu