Tianocore/edk2.git/BaseTools, branch dependabot/github_actions/actions/setup-python-7

BaseTools: Add support for preserving build ID

2026-07-22T18:06:03+00:00

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

BaseTools/Trim.py: Strip "#pragma once" from inlined ASL content

2026-07-17T21:50:16+00:00

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

BaseTools/build.py: Use full source file path for dependency generation

2026-07-17T10:54:11+00:00

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

BaseTools/Tests: Update TC6 for backward-compatible rebase behavior

2026-07-15T21:37:05+00:00

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

BaseTools/GenFv: Preserve legacy rebase behavior when Xip is unused

2026-07-15T21:37:05+00:00

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

BaseTools/Plugin/CodeQL: Add CodeQL version update script

2026-07-11T01:26:20+00:00

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

BaseTools/Plugin/CodeQL: Update CodeQL CLI to v2.25.3

2026-07-11T01:26:20+00:00

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

BaseTools/GenFds: Print INF name on Depex eval failure

2026-07-09T09:58:04+00:00

Signed-off-by: Christopher Zurcher

BaseTools: Enable stack protector for LoongArch64

2026-07-07T08:49:21+00:00

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 Cc: Liming Gao Cc: Guillermo Antonio Palomino Sosa Cc: Yuwei Chen Cc: Poncho Figueroa Cc: Mike Beaton

BaseTools: Remove VS2017 support

2026-06-30T21:42:50+00:00

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