Running the vulture tool on the Capsule folder gave the following
report. Remove the unnecessary code.
- Capsule/WindowsCapsuleSupportHelper.py:26:
unused method 'RegisterHelpers' (60% confidence)
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Running the vulture tool gave the following report.
Remove the unreachable code.
- TargetTool/TargetTool.py:49:
unreachable code after 'raise' (100% confidence)
- UPT/Library/UniClassObject.py:137:
unreachable code after 'return' (100% confidence)
- UPT/Object/Parser/InfDefineObject.py:795:
unreachable code after 'if' (100% confidence)
- Ecc/Check.py:1504:
unreachable code after 'return' (100% confidence)
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Verify that the subject line matches the basic
{Package}[,Package]:
format _or_ the
Revert "<subject of commit to revert>"
format.
Non-package top-level directories are treated as packages.
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
In order to enable subject line format compliance checking in following
patches, pass through a list of modified packages to CommitMessageCheck.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
The get_parent_packages function in CheckGitCommits returns the path of
non-package directories, but in fact returns the path of the .dec file
for actual packages.
Align the handling to be more consistent and return only directory names,
regarding of how it was found.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
$(DEBUG_DIR)/<M>.efi is generated by the recipe of
$(OUTPUT_DIR)/<M>.efi: the .efi file is generated and then copied into
$(DEBUG_DIR). At the moment the generate GNUmakefile does not declare
the dependency between these two files, which can be a problem because
$(FFS_OUTPUT_DIR)/<M>.offset depends on $(DEBUG_DIR)/<M>.efi.
Normally $(DEBUG_DIR)/<M>.efi is generated first and there is no
problem, but when an external tool builds edk2 from a Makefile, like
OP-TEE build does for instance, the parallel '-j' flag passed to Make is
inherited by the edk2 GNUmakefile from the environment. As a result Make
might try to build the $(FFS_OUTPUT_DIR)/<M>.offset target in parallel
and fail to find the .efi file:
make[1]: *** No rule to make target 'Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/NetworkPkg/VlanConfigDxe/VlanConfigDxe/DEBUG/VlanConfigDxe.efi', needed by 'Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/FV/Ffs/E4F61863-FE2C-4b56-A8F4-08519BC439DFVlanConfigDxe/VlanConfigDxe.offset'. Stop.
If we declare the $(DEBUG_DIR) file as output of this rule, then the
generated GNUmakefile will contain the right dependency declaration:
$(DEBUG_DIR)/VlanConfigDxe.efi: $(OUTPUT_DIR)/VlanConfigDxe.efi
and the parallel build will succeed.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Building .aslc files in a module for host-based unit
testing in Linux/GCC X64 environments may introduce
relocations for a symbol in a shared library from
lcov or asan.
Update logic to not generate an error message and exit
if the symbol is unknown but the relocation type is
R_X86_64_NONE.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Ignore mismatch errors for lcov 2.x in all locations that lcov
is run. When building more complex unit tests, these mismatch
errors are showing up in different phases of the code coverage
collection.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.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>
Fixes a BaseTools Bin directory path detection bug in the the BaseTools
Unit Tests. The script incorrectly assumes that sys.platform
will be win64 on a 64-bit Python interperter.
The "win64" platform string has not been used for 64-bit Python
interperters since May 10, 2000:
https://github.com/python/cpython/commit/da5cc82d
Moreover, this patch was merged before the Python 2.0 release, so there
never has been a released Python interperter that used the "win64"
string.
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
PatchCheck error messages can be improved by adding the line number.
The line itself may consist of only whitespace for some errors.
Adding the line number can help better locate the error source.
Signed-off-by: Gary Beihl <garybeihl@microsoft.com>
Add GUID section for build report.
Also, change the GUID format to string format to be easier to parse
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
BaseTools currently does not expand macros for component architecture when
nested !include directives are used. This breaks use cases like
[Component.$(DXE_ARCH)].
The fix is to add explicit macro expansion when computing the Arch value
for component lines in DscParser.
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Alignment needed to be updated to 64 because of a linker warning
when building with MSVC.
/ALIGN:64 is the minimum alignment for MSVC ARM64, which differs from
MSVC x64. This was missed when checking into edk2 because CI isn't
run for MSVC ARM64.
Signed-off-by: Vivian Nowka-Keane <vnowkakeane@linux.microsoft.com>
/WX was added as a build flag in VS2022 and now aarch64 builds
fail because of an undocumented linker warning: 4226 Alignment specified
exceeds target machine page size.
This linker warning has always occured and can be ignored.
Signed-off-by: Vivian Nowka-Keane <vnowkakeane@linux.microsoft.com>
This change enables the emission of C preprocessor
line-markers for VFR intermediate files on the GCC and
Clang compilers.
Since the VfrCompiler now supports GCC-style preprocessor
line markers, they can be enabled by default.
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
This change adds support for GCC-style preprocessor line
directives as documented in:
https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html
On Windows systems, one can use line-markers to see which .vfr
file was used to generate a *.i file in the Build directory.
This is useful for debugging VFR compilation failures.
With this change, the VfrCompiler will not generate compilation
errors if the *.i file contains GCC-style line-markers. Without
this change, one must disable the pre-processor's emission of
line-markers, removing the debug aid they provide.
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
The following example fails to be parsed correctly due to Size
being used in the outer scope but initialized in the inner
scope
```
gPlatformPkgTokenSpaceGuid.PcdSecureBootDbxBinaryFile|{}
```
Problematic code:
```python
for Item in NewPcdValueList:
Size = 0
# ....
if Size > 0:
PcdValue = '{' + ', '.join(AllPcdValueList) + '}'
````
Signed-off-by: Doug Flick <dougflick@microsoft.com>
When using the replace function, if the replaced file
located in a compress section, then the tool will re-build
the section. As the compress status set in the wrong place,
in some situation, the compress will do twice times which is
a wrong behavior.
This patch is used to fix this issue.
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Ashraf Ali S <ashraf.ali.s@intel.com>
Signed-off-by: Yuwei Chen <yuwei.chen@intel.com>
When a module M depends on L1, which depends on L2,
which depends on L3, the build fails when the library instance
of L3 cannot be found according to the library class-instance
mapping configuration specified in the DSC file.
When such failure happens, the build tool only prints that the
instance of L3 required by module M cannot be found. But it
does not tell how L3 is required by M.
The change enhances build tool to print the entire dependency
chain when such failure happens.
With the change, the new error message will be as follows:
<dsc-path>(...): error 4000: Instance of library class [L3] is not
found for module [M], [L3] is:
consumed by <instance of L2>
consumed by <instance of L1>
Signed-off-by: Ray Ni <ray.ni@intel.com>
If an FV_SPARE_SPACE_THRESHOLD is enabled and an FV
is 100% full with 0 bytes free, then this is likely
a special FV that may have alignment requirements
for the FFS file for both the start address and the
length and the FFS file consumes all the available
FV space.
Reduce FV_SPARE_SPACE_THRESHOLD from an error to a
warning if this FV 0 bytes free condition is
detected.
PR #10828 introduced the generation of these error
conditions for an FV with large alignment requirements.
The pad region before the aligned FFS file used to
be counted as free space even though it could never
be used due to the alignment requirements. There was
actually no free space available. PR #10828 fixed the
free space calculation to properly show it as 0 bytes
free, and this change then caused build error when
FV_SPARE_SPACE_THRESHOLD feature was enabled. The
reduction to a warning for this condition allows the
build to complete with errors and also provides a
build log warning message for review.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
- FMMT tool would use the "PATH" environment variable for locating
the required GUID tool.
- On Windows-like system, batch file not found in the "PATH" environment
variable when "shell=False".
- This issue required commands to include program extensions or
absolute paths.
- This patch sets "shell=True" to extend the support for batch files,
including scripts in BinWrappers under BaseTools.
- Converted input commands from lists to strings to ensure proper
argument interpretation in POSIX-like shell scripts.
Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
In case of the FV with VTF, the left size should be enough to add the
minimum pad file size (EFI_FFS_FILE_HEADER, 0x18). It prevents the build
error, "GenFv: ERROR 0006: invalid FFS file header checksum" caused by the
pad file overwriting some header data in VTF. This includes these updates
for CalculateFvSize() function.
1. If NumBlocks is not defined, ensure the minimum pad file size for the
left size (if the pad file is required as VTF is not bottom aligned at end
of block, insert EFI_FFS_FILE_HEADER to ensure the pad file size)
2. If NumBlocks is defined, report more clear error message (the required
fv image size = 0x%x. the set fv image size = 0x%x. Free space left is not
enough to add a pad file (0x18))
3. Remove MaxPadFileSize, which is reported when the taken size is same as
the total size. It can not be the actual left size to add an FFS file. It
causes confusion when referring to the build log (FV Space Information)
Signed-off-by: Phil Noh <Phil.Noh@amd.com>
- In the commit 42a141800c
there was a misuse of "is_dir" method.
- Treating it as an object rather than function call,
which caused if-condition to always as "false".
- No files would be added to scanning list due to incorrect usage.
- This patch corrects the issue by properly using "is_dir()".
Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
VS2019/VS2022 ARM/AARCH64 is not a widely used toolchain, for one
thing edk2 can't be built with it, it will break. Downstream
platforms rarely use it and if they do, they must have heavy edits
in order to support building edk2. In particular, edk2 does not
have support for the assembly files that this toolchain uses fully.
As a result, the corresponding StackCheckLib does not have the assembly
file needed to satisfy the definitions the compiler expects.
Unfortunately, the VS ARM/AARCH64 compiler has a different ABI than
the IA32/X64 VS toolchain for stack cookies, so this also needs more
investigation.
For now, disable stack cookie checking in VS ARM/AARCH64 as this does
not affect many platforms. However, it does allow for the use case
reported in the bug mentioning this, which is building a shell and
attempting to boot to it.
When VS ARM/AARCH64 support is revisited in edk2 (or if there is a
clean way to add stack cookie support without the full support), this
will be revisted.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.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>
Commit c6f47e6 removed BUILDRULEFAMILY for CLANGDWARF. Adding
CLANGDWARF back as a BUILDRULEFAMILY to match CLANGPDB.
Add CLANGDWARF specific build rules - based on GCC, and remove steps
not required for CLANGDWARF.
Remove following irrelevant steps and logs:
...
"objcopy not needed ..."
"--strip-unneded ..."
"--add-gnu-debuglink ..."
...
Signed-off-by: Vishal Oliyil Kunnil <quic_vishalo@quicinc.com>
In the case that the total provided to the `_show_progress()`
function is zero, do not show a progress bar to prevent aborts
`ZeroDivisionError` when calculating the progress percentage.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
If command line options are moved into a response file
of a GCC family build, then the file path separators are
converted from '\' to '/'. However, this can corrupt
command line options that are quoted strings.
Update GenMake to no convert '\' to '/' in quoted strings.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
The linker option 'no-warn-rwx-segments' breaks both the LLVM linker and
versions of the binutils ld.bfd linker prior to 2.39.
Now that the ELF image is made up of separate R-X and RW- segments, this
warning is no longer emitted and so there is no longer a need to
suppress it either.
While at it, move GCC_DLINK_FLAGS_COMMON (which is not common but only
used by Ia32 and X64) into its only user so it can be dropped.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
To prevent the ELF linkers from complaining about emitted ELF segments
that require both writable and executable permissions, define two
separate R-X and RW- ELF segments, and emit the output sections
explicitly into those segments as appropriate.
Note that this has no bearing on the PE image, and using a single RW-
segment would probably be fine too.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The original reason for creating a separate version of the ELF linker
script for Clang was the difference between COMMONPAGESIZE and
MAXPAGESIZE, which can we provided on the command line to the respective
linkers (ld.bfd versus lld). That difference no longer exists, and both
use COMMONPAGE_SIZE. So there is no longer a need to maintain a fork,
which has already been going out of sync with the original for no good
reason.
So merge the two and call it GccBase.lds
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The GccBase.lds and ClangBase.lds ELF linker scripts have been laid out
very carefully to ensure that the memory mappings of .text and .data are
such that they can be preserved in the PE/COFF memory image. This
removes the need to update any place-relative ELF relocations when
generating the PE/COFF image, making its job much easier, and
potentially allowing it to disregard static ELF relocations altogether,
and rely solely on dynamic ELF relocations.
Adding an arbitrary .entry section before .text breaks those
assumptions, so instead of emitting it as a separate section, move its
payload to the start of .text.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The command line option --no-warn-rwx-segments was added to the linker
command line for all GCC family builds on ARM and AARCH64, including
CLANGDWARF and GCC49 and older, none of which are intended for use with
linkers that actually understand this option.
So instead, move it to the GCC5 DLINK FLAGS definitions for ARM and
AARCH64 (which are inherited by the versionless GCC which is intended to
replace GCC5 at some point).
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The prehistoric code base doesn't build with ISO C23. Set the C
standard to C11 (for both clang and gcc) so it continues to build with
gcc 15 (which uses C23 by default).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch addresses an issue in the FMMT operations where the parent
reference is not checked for NoneType. This oversight can lead to an
AttributeError: 'NoneType' object has no attribute 'Name' when
attempting to access the parent reference. The fix involves adding a
check for NoneType before accessing the parent reference to ensure that
the operations handle such cases gracefully.
The affected functions include:
- AddNewFfs
- ReplaceFfs
- ExtractFfs
These functions now include proper checks to prevent the AttributeError.
Signed-off-by: Ashraf Ali S <ashraf.ali.s@intel.com>
Today VS2022 and GCC are set to treat all compiler warnings as
errors and break the build. However, linker warnings for both
do not break the build. There are critical errors that can be
treated as warnings as the linker, such as not finding the
module entry point and use a default address as the entry
point. This will cause a runtime crash for something that
should be caught at build time.
This commit adds /WX to VS2022's DLINK_FLAGS and --fatal-warnings
to GCC's DLINK_FLAGS for IA32, X64, ARM, and AARCH64 in order to
break the build on linker warnings.
VS2022 linker warning 4210 is ignored for all builds because it
checks for static initializers and the linking of the VCRuntime.
edk2 never links the VCRuntime (except for HOST_APPLICATIONs) and
so the presence of static initializers will always cause this
warning, even when the edk2 code calls these initializers that
would otherwise be called in the _CRT_INIT function of the
VCRuntime. At the time of this commit, it only fails in CryptoPkg
for building OpenSSL, but could fail anywhere a static initializer
is used.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
The environment variable `GTEST_CATCH_EXCEPTION` must be
set to `0` for so all exceptions are handled by the
address sanitizer and not GoogleTest. This allows stack
back trace and other details to be logged by the address
sanitizer so the source of the issue identified address
sanitizer can be determined.
The environment variable `ASAN_OPTIONS` must be set to
`detect_leaks=0` to disable memory leak detection. The
unit test frameworks may have memory leaks and some
firmware code under test use cases may perform a memory
allocation without a matching memory free as their
expected behavior.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
