Tianocore/edk2.git/BaseTools/Source/Python, branch master

BaseTools/FirmwareStorageFormat: Fix FV ext entry struct factory functions

2026-09-13T19:05:51+00:00

The Refine_FV_EXT_ENTRY_OEM_TYPE_Header() and Refine_FV_EXT_ENTRY_GUID_TYPE_Header() functions incorrectly return an instantiation attempt of the local class with `Structure` as an argument (e.g., `return ClassName(Structure)`) instead of returning the class itself (e.g., `return ClassName`). This causes FMMT to fail with: "expected EFI_FIRMWARE_VOLUME_EXT_ENTRY instance, got _ctypes.PyCStructType" When processing FVs that contain ext header entries of type 0x01 (OEM Type) or type 0x02 (GUID Type, used for FV UI Name when FvNameString = TRUE). Fix by returning the class directly, matching the pattern used by Refine_FV_Header() which correctly returns the class for subsequent .from_buffer_copy() calls. Signed-off-by: Michael D Kinney

BaseTools: Optimize parsing of byte-array PCD values

2026-09-06T23:50:31+00:00

This change adds a fast path for simple VOID* hexadecimal byte arrays, avoiding the generic expression tokenizer's repeated processing of large PCD values. Regression tests for both paths. It does not change the existing parser for structured and symbolic expressions. This reduces parsing time for a 28 KiB generated PCD from roughly 2 seconds to 50 milliseconds. Signed-off-by: Kun Qin

BaseTools: Make DSC arch macro expansion owner-aware

2026-09-01T14:42:26+00:00

PR #12628 expanded architecture macros for every DSC record so component-private records match their component. A positive raw owner can also represent include provenance, so broad expansion changes records outside component scope. Expand architecture macros only for Component records and records whose owner maps to a final Component. Reset the owner mapping whenever the post-processed table is rebuilt to prevent stale ownership across DoPostProcess calls. Add regression coverage for component-private LibraryClasses and PCDs, nested and private includes, multiple architectures, unresolved macros, repeated sections, and repeated post-processing. Signed-off-by: Bob Chen (UST Global Singapore Pte Limited)

BaseTools/Python: Remove error message with email address

2026-08-28T10:04:05+00:00

Remove the "Please send email to devel@edk2.groups.io" message from the unhandled exception handlers in build.py, GenFds.py, Trim.py, and the UPT tools. Also remove the now-unused MSG_EDKII_MAIL_ADDR and MSG_SEARCH_FOR_HELP constants from Common/DataType.py and UPT/Logger/StringTable.py. Signed-off-by: Vishal Oliyil Kunnil

BaseTools/Build: Output warning message for library class mismatch

2026-08-06T04:55:34+00:00

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 Co-authored-by: Poncho Figueroa

BaseTools: Fix Clang -Wtautological-overlap-compare in PcdValueInit.c

2026-08-01T16:17:54+00:00

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

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/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