Tianocore/edk2.git/BaseTools/Source, 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/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/GenFds: Print INF name on Depex eval failure

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

Signed-off-by: Christopher Zurcher

BaseTools/Ecc: Add check for traditional include guards

2026-06-26T02:18:38+00:00

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

BaseTools: Fix MODEL_IDENTIFIER_MACRO_PROGMA typo

2026-06-26T02:18:38+00:00

Fixes typo in the constant name. Signed-off-by: Michael Kubacki

BaseTools/Build: Fix arch macro expansion scope in DSC parser

2026-06-23T02:21:25+00:00

Signed-off-by: Kirk Chou

BaseTools/GenFds: Fix FV attribute parser to allow any keyword order

2026-06-22T15:18:12+00:00

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

BaseTools/GenFds: Allow PE32 section keywords in any order

2026-06-22T15:18:12+00:00

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