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>
lcov v2.0+ treats several gcov/source-related conditions as fatal
errors that were previously warnings in v1.x. This causes coverage
capture to abort when the build tree includes vendored third-party
sources (e.g. OpenSSL) that produce gcov mismatches, missing source
references, unexpected gcov output, or non-zero gcov return codes.
Signed-off-by: Doug Flick <dougflick@microsoft.com>
Certain environments require Control Flow Guard (CFG) to be enabled at
build time as part of their security hardening requirements.
This change adds the necessary compiler and linker flags to enable CFG
support.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
Add conditional suppression of MSVC warning C4028 (formal parameter
different from declaration) when building with Visual Studio 2017 or
earlier toolchain.
This warning is triggered by brotli submodule and not emitted by newer
compilers, hence a conditional supression is used.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
This change fixes a warning newly emitted by the latest MSVC, which now
treats this warning as an error and causes the build to fail.
This change aligns operand types in bitwise expressions by casting sizeof
results to UINT32, and promoting a UINT32 to UINTN where required to
correctly apply the bitmask.
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
Add --source-code-format option that can be NASM or not
specified. This can be used for file format specific actions
when --source-code is used.
A NASM specific action is added to convert #line to %line to
preserve reference the originating NASM source file for source
level debug in NASM format.
Without this change, the source level debug of NASM files
loads the generated intermediate file in the build output
directory.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
The CParser4 Python parser files (CLexer.py, CParser.py, CListener.py)
were generated 7 years ago with ANTLR 4.7.1.
Meanwhile, pip-requirements.txt pins antlr4-python3-runtime to version
4.9 in commit 4a7dd50, but the files were patched, not fully
regenerated. This version mismatch could result in failures when
running against non-trivial C code.
This change regenerates the CParser4 files with ANTLR 4.9 to resolve
the version mismatch. It also updates import statements to correctly
reference Eot instead of Ecc.
Steps used to regenerate the files:
1. Download the ANTLR 4.9 complete tool JAR:
- `https://www.antlr.org/download/antlr-4.9-complete.jar`
2. Generate Python3 parser files
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
The CParser4 Python parser files (CLexer.py, CParser.py, CListener.py)
were generated 7 years ago with ANTLR 4.7.1.
Meanwhile, pip-requirements.txt pins antlr4-python3-runtime to version
4.9 in commit 4a7dd50, but the files were patched, not fully
regenerated. This version mismatch produced two failures when running
EccMain.py against non-trivial C code:
1. A runtime warning on every file parsed:
"ANTLR runtime and generated code versions disagree: 4.9!=4.7.1"
2. A crash when parsing complex C constructs that exercise the
struct/union definition rule in CParser.py:
TypeError: '<' not supported between instances of 'tuple' and 'int'
This occurs in antlr4/BufferedTokenStream.py getText() because the
4.9 runtime changed the expected argument types for that method,
and the 4.7.1-generated parser was passing a tuple where an int is
now required.
This change regenerates the CParser4 files with ANTLR 4.9 to resolve
the version mismatch.
Steps used to regenerate the files:
1. Download the ANTLR 4.9 complete tool JAR:
- `https://www.antlr.org/download/antlr-4.9-complete.jar`
2. Generate Python3 parser files from the grammar:
```
java -jar antlr-4.9-complete.jar `
-Dlanguage=Python3 -visitor `
-o BaseTools/Source/Python/Ecc/CParser4_new `
BaseTools/Source/Python/Ecc/CParser4/C.g4
```
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Add include guards back to include files that use the same
include guard macro in BaseTools/Source/C/Include/Common
and MdePkg or MdeModulePkg.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
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 <michael.d.kinney@intel.com>
Since
ae83c6b7fd
-Wno-unused-but-set-variable
-Wno-unused-const-variable
-Wno-unused-variable
warning suppression is no longer needed in any builds, and the
warnings can be re-enabled to catch real errors.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
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 <michael.kubacki@microsoft.com>
The codebase has moved from traditional `#ifndef` include guards to
`#pragma once`. Remove the ECC checks that validated include guard
presence and naming conventions since they are no longer applicable.
The following checks are removed:
- IncludeFileCheckIfndefStatement: Verified all header file contents
were guarded by a `#ifndef` statement, that the `#ifndef` was the
first line of code after the file header comment, and that the
`#endif` appeared on the last line.
- NamingConventionCheckIfndefStatement: Verified that the `#ifndef`
guard name at the start of an include file used a postfix underscore
and no prefix underscore character.
Also removed related error codes and configuration settings that were
specific to these checks.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
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 <michael.kubacki@microsoft.com>
This reverts commit 3fe1d56cc9.
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 <michael.d.kinney@intel.com>
This reverts commit f0542ae07d.
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 <michael.d.kinney@intel.com>
Use $(SEP) with addprefix of $(OBJDIR) to support Windows MINGW
CLANG builds that use Windows path separators with GNU makefiles.
This fixes Windows MINGW CLANG builds of the PcdValueInit
application that is required for structured PCDs.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
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 <ovt@google.com>
- Move common wrapper logic for multiple tools to GenericShellWrapper
file
- Drop search for BaseToolsCBinaries from the list of checked
directories. This case has been broken for quite a while since the
exec clause never passed command arguments to the supposed binary.
- Remove a suggestion to run make in $EDK_TOOLS_PATH/Source/C and let
the wrapper fail if the directory exists but no binary is present.
Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
VfrLexer.h is built as a part of VfrCompile build and
shouldn't be present at the BaseTools/Source/C level.
Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
As a preparation for out-of-tree build support make sure all interim
files for tests are created in tmp directory.
Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
SEP variable is only set if PYTHON_COMMAND is undefined but referred
regardless. It breaks the clean target for the following scenario:
. edksetup.sh # Sets PYTHON_COMMAND
make -C BaseTools
make -C BaseTools clean
This change fixes the use case mentioned above by settings SEP
for all build configurations.
[ardb: Drop redundant assignment for Windows]
Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
New warning after updating gcc:
EfiRom.c: In function ‘main’:
EfiRom.c:78:17: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
The assigned value is not used, so fix the warning by just removing it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
StringFuncs.c: In function ‘SplitStringByWhitespace’:
StringFuncs.c:113:15: error: variable ‘Item’ set but not used [-Werror=unused-but-set-variable=]
113 | UINTN Item;
| ^~~~
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The PCD value defined in module subsections can be added to global PCD
database. Therefore the unsolved expressions, even belongs to the global
scope, can incorrectly refer to the value from module subsection.
This only happens when the referred PCD has no value assignment in the
platform dsc file. Which also should raise an error.
Signed-off-by: Paddy Deng <paddydeng@ami.com>
Fix VS20xx build failures in GitHub Actions windows-2025
environments due to missing libraries.
Add WindowsSDKLibVersion to the set of environment variables
that are set in a Windows Visual Studio build environment.
WindowsSDKLibVersion is required to set LIBPATH for VS20xx
builds of the EmulatorPkg and Host-based unit tests.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Add %VCToolsInstallDir%\bin\Hostx64\x86 to PATH to add DLLs
required for IA32 host-based unit tests to execute.
Some Visual Studio environments add the IA32 DLL path to PATH
and some do not. The failure was observed in GitHub Action
windows-2025 agents where the X64 DLL path was added, but the
IA32 DLL path was missing.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
When compiling rc files in environments where file paths begin with "/",
llvm-rc may incorrectly interpret absolute paths such as "/User/..."
as command-line options (e.g., "/U", "ser", "..."). This results in the
error "Exactly one input file must be specified". The issue was
initially observed on macOS, where user data is commonly located under
"/User" rather than "/home", but was later found to affect all platforms
where file paths start with "/". Using double hyphens ensures that all
arguments to the right are treated as positional arguments rather than
options. The use of double hyphens is supported by the LLVM command-line
argument parser and is safe in all such environments.
See: https://llvm.org/docs/CommandLine.html
Section: Specifying positional options with hyphens
Signed-off-by: Alexander Gryanko <xpahos@gmail.com>
This change adds the support for building AARCH64 target platforms using
CLANGPDB.
This applies a 4KB section alignment for all AArch64 modules built
with CLANGPDB for multiple reasons:
- DXE and Standalone MM modules should have memory protections applied
- There is a bug in llvm that allows for code generation that ends up
requiring 4KB section alignment, see
https://github.com/llvm/llvm-project/issues/172660.
This also adds a build rule to use DLINK_XIPFLAGS to ensure a file
alignment of 4KB for SEC/PEI modules to ensure file alignment and
section alignment match.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
