Tianocore/edk2.git/BaseTools/Source/C/VfrCompile, branch master

BaseTools/Source/C/VfrCompile: Fix parallel make failures

2026-02-27T04:54:43+00:00

Update makefile rules to run antlr and dlg to completion before compiling any of the generated cpp files. Without this change, parallel make may start compiling some of the cpp files before both antlr and dlg have finished which produces syntax errors from compilation with partially generated files. Also use &: so the targets are treated as a group and the rule is only executed once for the entire group. Without this change, parallel make may run the rule actions more than once and modify the output while it is being used by another rule. Signed-off-by: Michael D Kinney

BaseTools: Replace include guards with #pragma once

2026-02-23T21:01:28+00:00

Replace traditional `#ifndef`/`#define`/`#endif` include guards with `#pragma` once. `#pragma once` is a widely supported preprocessor directive that prevents header files from being included multiple times. It is supported by all toolchains used to build edk2: GCC, Clang/LLVM, and MSVC. Note: Some files in BaseTools are excluded from the change if they are autogenerated or direcly related to a header from a subproject, etc. In particular, headers in these directories were ignored: - BaseTools/Source/C/LzmaCompress/Sdk/ - BaseTools/Source/C/VfrCompile/Pccts/ Compared to macro-based include guards, `#pragma once`: - Eliminates the risk of macro name collisions or copy/paste errors where two headers inadvertently use the same guard macro. - Eliminate inconsistency in the way include guard macros are named (e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.). - Reduces boilerplate (three lines replaced by one). - Avoids polluting the macro namespace with guard symbols. - Can improve build times as the preprocessor can skip re-opening the file entirely, rather than re-reading it to find the matching `#endif` ("multiple-include optimization"). - Note that some compilers may already optimize traditional include guards, by recognzining the idiomatic pattern. This change is made acknowledging that overall portability of the code will technically be reduced, as `#pragma once` is not part of the C/C++ standards. However, this is considered acceptable given: 1. edk2 already defines a subset of supported compilers in BaseTools/Conf/tools_def.template, all of which have supported `#pragma once` for over two decades. 2. There have been concerns raised to the project about inconsistent include guard naming and potential macro collisions. Approximate compiler support dates: - MSVC: Supported since Visual C++ 4.2 (1996) - GCC: Supported since 3.4 (2004) (http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html) - Clang (LLVM based): Since initial release in 2007 Signed-off-by: Michael Kubacki

BaseTools/VfrCompile: Add #pragma once support

2026-02-23T21:01:28+00:00

The C preprocessor turns each .vfr file into a pre-processed .i file. At this step, the C preprocessor processes `#pragma once`. Then, VfrCompile is called (with `-n` to prevent preprocessing) to parse the pre-processed .i files. The .i files may still contain `#pragma once` lines. Currently, VfrCompile treats `once` as an unknown token, causing parse failures. Originally, this change was going to add a `PragmaOnce` token rule to the VFR lexer grammar (in VfrSyntax.g) that matched `#pragma once` lines and silently skipped them using `skip()` and `newline()`. The `newline()` call would keep line numbers stable for error reporting. This was consistent with how other preprocessor artifacts were already handled like `#line` directives (`LineDefinition` and `GccLineDefinition` tokens) and `extern` declarations (skipped with `mode(CPP_COMMENT)`). Writing a regular expression to match `#pragma once` was simple enough, but it makes overall pragma token recognition more fragile at the lexer level. When the lexer is walking the DFA state table, it could begin to match a `#pragma ` line but then not be able to match remaining characters to recognize tokens other than `once`. Instead, this change handles `#pragma once` lines in the VFR parser grammar in `vfrPragmaDefinition` alongside where `pack` is already handled. Signed-off-by: Michael Kubacki

Revert "BaseTools: Add support for out-of-tree builds"

2026-02-11T22:53:29+00:00

This reverts commit 3fe1d56cc98e011bbde8348f13dfa5e38c95f49e. PR https://github.com/tianocore/edk2/pull/11757 introduced a "Breaking Change" feature for out of tree builds of tools. This breaking change is blocking testing of edk2-stable202602 due to side effects on building FitGen tool in edk2-platforms. Revert this feature for the edk2-stable202602 release and work on this feature after the release. Signed-off-by: Michael D Kinney

BaseTools: Add support for out-of-tree builds

2026-02-02T08:56:31+00:00

Main EDK2 build supports out-of-tree builds but BaseTools make process still creates tools and object files in-tree. In order to make out-of-tree build support complete move the generated tools and interim obj files to $WORKSPACE location as well. This patch also changes the location of BaseTools for in-tree builds (default behavior when WORKSPACE is not provided before calling edksetup) to $WORKSPACE/BaseTools/Build/... It may potentially break external workflows that invoke tools from the default location outside of the build tool. Signed-off-by: Oleksandr Tymoshenko

BaseTools: GNUMakefiles must use CMD.EXE in Windows

2025-12-24T02:03:38+00:00

Use $(OS) in all GNUMakefiles to detect if the GNUMakefile is being used in a Windows OS. If a Windows OS is detected, then override SHELL to use cmd.exe. This prevents make utility from using sh.exe if sh.exe happens to be in PATH. If sh.exe is used, then backslash (\) characters in file paths are removed and builds break for files not found. Signed-off-by: Michael D Kinney

BaseTools: Fix multiple security vulnerabilities (Defense in Depth)

2025-12-22T04:53:27+00:00

Signed-off-by: 20000419

BaseTools/VfrCompile: Minor code cleanup

2025-12-03T12:29:51+00:00

There are no functional changes in this commit. It adds non-functional minor code cleanups made while tracking down the bugs fixed in the preceding commits. - Fix spelling 'arrary' -> 'array' where it occurs in the tool code and comments. - When renaming ExtractFieldNameAndArrary to ExtractFieldNameAndArrayIdx, we fix the typo and also clarify what the method does: it returns the field name and the array index when present. Since it is always used to populate a local variable named ArrayIdx, we stick to that spelling in the renamed method. - Add comment clarifying that mArrayNum holds array length (but again, don't go for a bigger global rename). - Rename CVfrVarDataTypeDB::GetFieldWidth to GetFieldType. It is only used once, and the new name correctly matches what it does. Signed-off-by: Mike Beaton

BaseTools/VfrCompile: Fix null pointer deref when dumping internal types

2025-12-03T12:29:51+00:00

Internal types such as pFormIdField, pFormSetGuidField have no associated field type, however the Dump command assumes that all types do. This causes null pointer dereferencing which can be caught by sanitizers. De facto, the field type for these types was already dumped as , this achieves the same safely. Signed-off-by: Mike Beaton

BaseTools/VfrCompile: Fix bit field access logic

2025-12-03T12:29:51+00:00

The previous logic for accessing bit fields is wrong when the bit field starts beyond the first byte, in a storage unit larger than a byte. This caused unaligned memory accesses which can be caught by sanitizers. We also bump the tool minor version number to reflect a functional bugfix. Signed-off-by: Mike Beaton