Performs a check that will verify that the library instance implements
the library specified in the dsc by ensuring a LIBRARY_CLASS definition
exists in the INF [Defines] section and the value matches the library it
says it is implementing.
As an example, from a platform dsc file:
BaseBmpSupportLib|MdeModulePkg/Library/BaseBmpSupportLib/BaseBmpSupportLib.inf
BaseBmpSupportLib is supposed to be of library class BmpSupportLib, but the
dsc defines it incorrectly, the warning message will be displayed during
build.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
Co-authored-by: Poncho Figueroa <poncho.figueroa.esqueda@intel.com>
For each structured-PCD field copied via memcpy, DscBuildData.py
emits the clamp expression, '(FieldSize > 0 && FieldSize < ValueSize) ?
FieldSize : ValueSize'. When ValueSize == 1 and FieldSize is unsigned,
it reduces to (FieldSize > 0 && FieldSize < 1) - always-false comparison.
Clang flags it under -Wtautological-overlap-compare, and because
PcdValueInit builds with -Werror, autogen fails and the build aborts with
'PcdValueInit.c: error: overlapping comparisons always evaluate to false
[-Werror,-Wtautological-overlap-compare]'. This is specific to Clang host.
To fix it, this update changes '<' to '<=' at all five generator sites in
DscBuildData.py (GenerateDefaultValueAssignFunction,
GenerateInitValueFunction, GenerateCommandLineValue,
GenerateModuleScopeValue, GenerateFdfValue). Behavior is unchanged:
both branches copy the same byte count when FieldSize == ValueSize.
GCC and MSVC builds are unaffected.
Signed-off-by: Phil Noh <Phil.Noh@amd.com>
This change updates the iasl binary to the 20230628 release.
The updated release also adds support for execution on ARM host machines.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
edk2 is moving to VS2026 for the MSVC toolchain,
as such, upgrade the Windows BaseTools build default
from VS2022 -> VS2026.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
Adds an optional flag that copies the GNU build-id note from the input
ELF file into the output PE/COFF firmware image as a dedicated ".bldid"
section. The build ID is emitted by the linker as a unique fingerprint
of the binary and allows custom post-build and debugging tools to
reliably match a firmware image against its corresponding unstripped
ELF and debug symbols, without relying on file names, timestamps, or
build paths.
This notable opts to use a non-standard section name ".bldid" to store
the build ID. This approach was chosen to keep genfw and the parsers simple
since the full "build-id" name would require redirecting the section name.
While this breaks from standard conventions, this is not impactful since
GenFW is already creating a non-standard artifact for the PE image with
the associated ELF symbol file.
Signed-off-by: Chris Fernald <chfernal@microsoft.com>
When Trim processes an ASL file (`--asl-file`), it textually inlines
the body of every `Include()`'d file directly into the constructed
preprocessor input, once per include site.
Its has duplicate protection in the form of a circular-include stack
(`gIncludedAslFile`), that prevents A->B->A cycles. But, as far as
the script is concerned, each `Include()` is a unique include site.
Various combinations of includes and file types are possible and
handled slightly differently.
Starting with file types as defined in
BaseTools\Conf\build_rule.template:
- `.aslc`, `.act` files fall under `Acpi-Table-Code-File` and are
compiled, linked, and processed by genfw.
- `.asl`, `.Asl`, and `.ASL` files fall in `Acpi-Source-Language-File`
and are processed by Trim:
1. `Trim --asl-file` to produce a single combined .i file with
includes inlined.
2. `ASLPP` (ASL preprocessor, a C preprocessor) on the output of
Trim to produce a .iii file with all macros expanded and
conditional branches resolved. AutoGen.h is also included and
processed here to resolve fixed PCD values if needed.
3. `Trim --source-code` which takes the pre-processed .iii file and
produces a .iiii file with content like linemarkers cleaned up.
4. The ACPI compiler compiles the .iiii file to produce AML bytecode
in a .aml file.
Because the `.aslc`/`.act` files are directly passed to normal C
processing tools, they are not part of the Trim change made in this
commit and the remainder of this message focuses on the ACPI Source
Language File case.
ASL files can use either an ASL `Include()` directive or a C-style
`#include` directive. In addition, different file types may be
included such as a `.asl` file or a `.h` file.
`Trim` handles these cases differently:
- For ASL `Include()` directives, `Trim` inlines the content of the
included file directly into the output at the include site. This is
done for all included ASL files regardless of their extension. The
inlining is purely textual and does not attempt to resolve or
preserve any preprocessor directives such as `#pragma once` or
include guards.
- For C-style `#include` directives, `Trim` checks the file extension
of the included file. If the file is an ASL file (`.asl` or `.asi`),
`Trim` treats the file the same as the `Include()` case. Otherwise,
`Trim` passes the directive through verbatim to the output, allowing
the downstream C preprocessor (`ASLPP`) to handle it according to
normal C preprocessor rules.
This creates a situtation in which the resulting `.i` might include:
- Inlined file content (from a `.asl` or `.h` file) depending on the
include type and file extension.
- Verbatim `#include` directives for non-ASL files which will be
processed by the C preprocessor.
Focusing on the "inlined" case, historically `.h` files would have
traditional C include guards (`#ifndef`/`#define`, `#endif`). However,
files might also include `#pragma once` as a guard.
In that case, the inlined content of the `.i` file could contain
multiple `#pragma once` directives, one per include site. When the
C preprocessor (`ASLPP`) processes the `.i` file, it sees multiple
`#pragma once` directives in what it considers the main file, and
could emit a warning like the following from gcc:
warning: '#pragma once' in main file [-Wpragma-once-outside-header]
The remainder of this commit message describes the change made to
address this warning.
This change strips "#pragma once" lines on the ASL content path in
`DoInclude()` in `Trim.py` so the directive is removed before it
reaches the C preprocessor.
- "#include" directives for non-ASL files are still passed through
verbatim for the C preprocessor to resolve where the contents of
those .h files might contain "#pragma once" or traditional guards.
- Traditional include guards are untouched and continue to behave as
before where multiple include sites might inline the same content
in the .i file before reaching the C preprocessor.
The change:
In the case that a file is inlined with a `#pragma once` directive,
the directive is stripped from the inlined content which prevents the
warning.
This is considered acceptable because it only removes the
`#pragma once` directive from the inlined content for these specific
cases. So, the `.i` file might contain multiple inlined copies of the
same header content (like always in this inline case) but without the
`#pragma once` directives. Because actual C content was already not
processed or trimmed out (e.g. `typedef struct`) duplicate content is
not considered to be a problem (`#define` multiple times is not a
problem for the C preprocessor).
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
During Silent build,NMAKE suppresses the command echo entirely.
As a result, the only output in ProcOut is the
MSVC compiler’s output lines.
Without the command echo, there is no full path in the output to
identify which source file is currently being compiled.
For unique basenames this is not an issue, but for namesake files
(for example, AmdSev.c located in different directories),
it is impossible to determine which file’s includes are being listed.
This change improves dependency generation for MSVC builds by introducing
explicit handling for source files with duplicate basenames
(namesake sources). A new variable current_source_abs is added to
consistently track the resolved absolute path of the active source file
instead of repeatedly recomputing it from SourceFileAbsPathMap.
To correctly resolve namesake files in silent builds
(where compiler commands are not echoed), a namesake_queue is introduced,
which preserves source ordering and sequentially maps basename occurrences
to their corresponding full paths.
Additionally, a cc_cmd_in_output flag is implemented to detect the presence
of compiler command lines in the output stream; when present,
source paths are derived directly from command-line arguments, otherwise
the queue-based resolution is used. This ensures correct mapping of
basenames to absolute paths across the silent builds, fixing incorrect
dependency generation when multiple source files share the same name.
Signed-off-by: Kowsik S <kowsiks@ami.com>
Update the test decision matrix and TC6 expected result to reflect
the backward-compatible ForceRebase logic: when ForceRebase=TRUE and
no files have the ,XIP suffix (XipFileCount==0), all files are
rebased using the legacy behavior rather than skipping all files.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Add XipFileCount to FV_INFO to track how many files have the ,XIP
suffix. Update FfsRebase() to only apply selective XIP rebase when
XipFileCount > 0. When no files have the ,XIP suffix (XipFileCount
== 0), preserve the legacy ForceRebase=TRUE behavior of rebasing all
files. This maintains backward compatibility for existing platforms
that use FvForceRebase=TRUE without any Xip rules.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Add a maintenance script that updates the CodeQL CLI dependency
YAML files and CodeQlQueries.qls together.
The script refreshes the CLI version, release digests, and cpp query
pack pin from the GitHub release metadata and the corresponding
qlpack.yml in the CodeQL CLI release branch.
Add comments to the CodeQL CLI dependency YAML files that direct
maintainers to use the script for future version updates.
Signed-off-by: Mingjie Shen <shen497@purdue.edu>
Update CodeQL external dependency definitions to v2.25.3 for generic,
Linux, and Windows archives, including refreshed SHA256 hashes from the
release metadata.
Pin the codeql/cpp-queries query pack to version 1.6.1, as specified in
the qlpack.yml at:
https://github.com/github/codeql/blob/codeql-cli/v2.25.3/cpp/ql/src/qlpack.yml
Signed-off-by: Mingjie Shen <shen497@purdue.edu>
LoongArch64 GCC or CLANG currently does not support the parameter
`-mstack-protector-guard=global`, but if `-fstack-protector` is enabled,
the guard is global.
The `-mstack-protector-guard` may be get supportted in the next GCC
release, possibly GCC17.
Signed-off-by: Chao Li <lichao@loongson.cn>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Guillermo Antonio Palomino Sosa <guillermo.a.palomino.sosa@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Cc: Poncho Figueroa <poncho.figueroa.esqueda@intel.com>
Cc: Mike Beaton <mjsbeaton@gmail.com>
Removes Visual Studio 2017 support from BaseTools. Newer toolchains
(VS2019, VS2022, and VS2026) are supported in its place.
This removes the VS2017 toolchain definitions from tools_def.template,
the VS2017 environment setup logic in toolsetup.bat,
set_vsprefix_envs.bat, and get_vsvars.bat, and the VS2017
configuration in the WindowsVsToolChain build plugin.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
REF: https://github.com/tianocore/edk2/issues/12490
Removes Visual Studio 2015 support from BaseTools since mainstream
support ended on October 13, 2020 and extended support ended on
October 14, 2025.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
This file has:
- Not been updated in 10 years.
- Was used to build Nt32Pkg which no longer exists.
- Is not needed to currenly build EmulatorPkg.
- Was last updated to support Visual Studio 2015, which is no longer
supported by Microsoft.
It is removed as part of the Visual Studio 2015 removal.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
This file:
- Has not had a code change in 8 years.
- Is not used by any other file in the repository.
- Was last updated to support VS2015 which is no longer supported by
Microsoft.
As part of VS2015 support removal, this file is deleted.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Adds a new ECC check, `IncludeFileCheckPragmaOnce` (error code 6006),
that flags header files using a traditional `#ifndef`/`#define`
include guard and recommends `#pragma once` instead.
A guard is detected when a '#ifndef NAME' is immediately followed by a
valueless '#define NAME' using the same macro name. Feature macros
such as '#define FOO 1' and files already using '#pragma once' are not
flagged.
The check reports against the parsed preprocessor directive rows in
the identifier tables rather than the File table. Those rows carry the
actual source line number, whereas File-level findings resolve to
"line 1" in the report. This gives an accurate line number, to the
EccCheck CI plugin, so it can reconcile findings with the changed line
ranges of a commit.
It uses the binary extension list and the exception list, consistent
with the other include file checks.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Switch GCC RISCV builds to use GCC_ALL_CC_FLAGS so that the -Os
compiler flag is applied during compilation.
For RiscVVirt target, this reduces DXEFV size by ~30%.
Signed-off-by: Tuan Phan <tuan.phan@oss.qualcomm.com>
Add TestFdfParserFvKeywordOrder test class with 8 parameterized
subtests verifying that FV-level keywords (FvForceRebase,
FvBaseAddress, FvAlignment) can be freely interleaved with FV
attribute flags in any order within an [FV] section.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Fix _GetFvAttributes() to return True when it has successfully parsed
at least one attribute before encountering a non-attribute keyword.
Previously it always returned False on encountering an unrecognized
word, even after consuming prior attributes. This caused the outer
parsing loop to break prematurely when FvForceRebase, FvBaseAddress,
or FvAlignment appeared between FV attribute flags (e.g. between
ERASE_POLARITY and MEMORY_MAPPED), resulting in a Python stack trace.
Move IsWordToken assignment to after successful attribute parsing and
change the early return from 'return False' to 'return IsWordToken'.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Add TestFdfParserPe32KeywordOrder test class with 17 parameterized
subtests covering all permutations of Align, Xip, and
RELOCS_STRIPPED/RELOCS_RETAINED keywords in PE32 section statements.
Tests verify pairwise orderings, all 6 three-keyword permutations,
single-keyword cases, and Xip=FALSE/RELOCS_RETAINED variants.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Replace sequential if-statements for Align, Xip, and
RELOCS_STRIPPED/RELOCS_RETAINED parsing in _GetEfiSection() with a
while-loop that accepts these keywords in any permutation. Previously,
specifying Xip before Align in a [Rule] PE32 section caused a Python
stack trace.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Add TestGenFvXip.py with 19 parameterized subtests covering the
complete XIP rebase decision matrix:
- 11 unit subtests validating DetermineXipEnabled() with
RuleComplexFile and RuleSimpleFile objects covering Xip attribute
parsing (TRUE/FALSE/None, case insensitive, boolean vs string).
- 8 functional subtests that run real edk2 builds with generated
DSC/FDF files exercising all ForceRebase/BaseAddress/Xip
combinations. Each test verifies:
1. FV INF file contains correct ,XIP suffixes
2. FV map file shows correct rebase status (Fixed Flash Address)
3. PE/COFF ImageBase in the FV binary matches expected value
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Update ParseFvInf() to detect and strip ",XIP" suffix from
EFI_FILE_NAME values in the FV INF file. Store the per-file XIP
flag in the new XipFile[] array in the FV_INFO structure.
Add FileIndex parameter to FfsRebase() so it can look up the XIP
flag for the current file. When ForceRebase is TRUE, only rebase
files that have their XipFile[] entry set to TRUE.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Add Xip attribute to FDF Rule class and parse the Xip keyword in
EFI section rules of FDF files. Add XipEnabled attribute to
FfsInfStatement that is determined from the applicable FDF Rule's
section Xip setting. When generating the FV INF file, append ",XIP"
to EFI_FILE_NAME entries for modules whose Rule specifies Xip=TRUE.
This enables per-file XIP rebase control in GenFv by communicating
which files require XIP rebase directly in the FV INF file format.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
GenFw converts linked ELF images to PE/COFF images using a new section
layout. The generated PE/COFF section RVAs are not required to match the
linked ELF section addresses, so relocation fixups that rewrite section
contents must use the generated PE/COFF RVA space.
A linker script layout change can expose this on LoongArch64 when .text
and .data are linked with 0x1000 alignment while .hii still keeps a
0x4000 alignment. GenFw then keeps a 0x4000 PE/COFF section alignment
because of .hii, producing different ELF and PE/COFF layouts.
Fix two LoongArch relocation paths exposed by this layout mismatch.
R_LARCH_64 entries stored in section contents, such as switch jump
tables, must be translated from the linked ELF section address space to
the generated PE/COFF RVA space. R_LARCH_PCALA_* and R_LARCH_GOT_PC_*
must also convert the referenced symbol to its generated PE/COFF RVA
before calculating the PC-relative offset.
The LoongArch ELF ABI defines PCALA/GOT_PC relocations as page-based,
but this GenFw path rewrites the HI/LO pair to PCADDU12I plus ADDI.D.
After that rewrite, the offset split must be based on the generated
PE/COFF instruction-relative offset.
For example, in the failing LogoDxe image, _gUefiDriverRevision is at
ELF address 0x5400 in .text, and the relocation referencing it is at ELF
address 0x104c. With ELF .text at 0x1000 and PE/COFF .text at 0x4000,
the generated PE/COFF RVAs are 0x8400 for the symbol and 0x404c for the
relocation site. Mixing the ELF symbol address with the PE/COFF
relocation-site RVA makes the entry wrapper read PE/COFF RVA 0x5400
instead of 0x8400, causing EFI_INCOMPATIBLE_VERSION.
Use PE/COFF RVAs consistently when rewriting LoongArch absolute and
PC-relative references during WriteSections64(). The existing
WriteRelocations64() base relocation emission is kept for load-time
image rebasing.
Reported-by: Chao Li <lichao@loongson.cn>
Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
Signed-off-by: Chao Li <lichao@loongson.cn>
Tested-by: Dongyan Qian <qiandongyan@loongson.cn>
Since most editors just ignore it, only source files get syntax
checked, and next to no one looks at their diffs before raising
a PR, trailing whitespace keep piling up in particularly this
file.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
Commit 87e486f defined a 3.07 version for tools_def.template, but the
version in the file was not updated. This commit updates the version
to 3.07 and includes changes made since 3.06.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Three invalid escape sequence SyntaxWarnings are reported because
`'\|'` is being escaped. This change consistently wraps all cases
where the character is used in double quotes, so the character is
preserved and the warnings are resolved.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Currently, Edk2BaseToolsBuild.py cleans before doing the build
on Linux, but doesn't do so on Windows.
It has been observed on Windows that the incremental build can
lead to a bad state of some logic from the old build and some from
the new build.
This commit aligns Windows to Linux and always do a clean before
building on both OSes.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
The relocation methods of R_LARCH_PCALA_HI20, R_LARCH_PCALA_LO12,
R_LARCH_GOT_PC_HI20 and R_LARCH_GOT_PC_LO12 have been optimized to
support cases where HI is not adjacent to LO and where one HI
corresponds to multiple LOs.
Signed-off-by: Chao Li <lichao@loongson.cn>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Guillermo Antonio Palomino Sosa <guillermo.a.palomino.sosa@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Cc: Poncho Figueroa <poncho.figueroa.esqueda@intel.com>
Cc: Mike Beaton <mjsbeaton@gmail.com>
- Within the capsule generate script, it is using the STDOUT result
as signature while signing the hash digest via OpenSSL tool.
- There would have incorrect result when the user terminal have
the output when executing the startup script.
- Incorrect the content of signature would make the verification failed.
- Use the "-output" flag to export the signature then read it back
as the resolution.
Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
When compiling an IA32 .aslc source file that includes Base.h, the GCC
static asserts for fundamental type sizes fail because 64-bit types such
as UINT64 are only 4-byte aligned by default in 32-bit mode. Adding
-malign-double causes the compiler to align 64-bit values on 8-byte
boundaries, matching the alignment assumed by the static asserts.
This fix is applied to the GCC, GCCNOLTO, CLANGPDB, and CLANGDWARF
toolchain IA32 ASLCC_FLAGS entries.
REF: #12517
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
When dumping LOONGARCH64 or RISCV64 Option Rom by `EfiRom -d test.rom`
command, the machine type is showed as `unknown`. This patch adds type
lookup strings for the two architectures.
Signed-off-by: Qihang Gao <gaoqihang@loongson.cn>
There is a bug in BaseTools currently when an inline
comment is used in tools_def. The comment is not
stripped out and wreaks havoc down the line,
causing BaseTools to get confused elsewhere and
drop build options it should be applying.
This fixes that behavior by following the build spec
which states:
Comments are only allows on separate lines and may not
be appended appear on actual entry lines.
Inline comments are now not allowed and the build will
fail and specify why and where.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
Currently, CLANGPDB X64 has 4KB section alignment and unwind
tables. CLANGDWARF has neither.
4KB section alignment is up for review in a separate PR, so this
commit adds unwind tables to DEBUG/NOOPT, matching both CLANGPDB
and other toolchains.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
Currently, the CLANGDWARF definitions for AARCH64 and RISCV64
(which was copied from the AARCH64 definitions originally) don't
follow the same pattern as CLANGDWARF IA32/X64 and the rest of
tools_def.template. This makes it harder to read and easier to
make an error (e.g. other toolchain define cc/dlink flags in
debug, release, noopt order, they do it in debug, noopt, release
order, so it would be easy to swap flags intended for release and
noopt).
This is a whitespace and comment only change, no flags are changed.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
Fix CLANGDWARF OBJCOPY errors for AARCH64 and RISCV64 by
setting OBJCOPY_FLAGS to an empty string so OBJCOPY actions
do not generate an error. This matches the IA32 and X64
settings for CLANGDWARF OBJCOPY_FLAGS.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
ANTLR 4.9 is broken in python 3.13 because
it uses a library in the autogenerated files
that is removed.
This updates to 4.13.2 and also updates the autogen
files, which contain support for python 3.13 as well
as backwards compat.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
The ANTLR autogen files are currently created
without an SPDX identifer. Add the BSD-2-Clause-Patent
ID.
While here, correct the command to do the autogeneration
by using the right filename.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
LinuxGccToolChain is checking for the environment variable
GCC_AARCH64_PREFIX when GCC_AARCH64_INSTALL is set in the environment
variables. GCC_AARCH64_INSTALL is set when any gcc aarch64 compiler
is installed (i.e. aarch64-none-elf, aarch64-linux-gnu, aarch64-unknown-elf
all result in a GCC_AARCH64_INSTALL environment variable).
When compiling for an X86 target, if an AARCH64 tool chain is installed
in the system, this will result in an error due to the GCC_AARCH64_PREFIX
not being set.
Add a check based upon TARGET_ARCH and and only verify the prefixes
when attempting to build AARCH64.
Replicate the same check for RISCV and LOONGARCH64 architectures as well.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
Reordering x64 toolchain defines (GCCS) to use a DLINK_XIPFLAGS
to set common-page-size to 0x40. Otherwise use default align
(0x1000 for x64).
Reorder CLANGDWARF toolchain defines to use DLINK_XIPFLAGS
to set common-page-size to 0x40 (matching existing behavior)
and otherwise use default linker value (0x1000 for x64).
Required modifying build_rule.template to support CLANGDWARF
build family for SEC, PEI_CORE, PEIM type files.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
