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 <chfernal@microsoft.com>
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 <michael.d.kinney@intel.com>
Update ParseFvInf() to detect and strip ",XIP" suffix from
EFI_FILE_NAME values in the FV INF file. Store the per-file XIP
flag in the new XipFile[] array in the FV_INFO structure.
Add FileIndex parameter to FfsRebase() so it can look up the XIP
flag for the current file. When ForceRebase is TRUE, only rebase
files that have their XipFile[] entry set to TRUE.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
GenFw converts linked ELF images to PE/COFF images using a new section
layout. The generated PE/COFF section RVAs are not required to match the
linked ELF section addresses, so relocation fixups that rewrite section
contents must use the generated PE/COFF RVA space.
A linker script layout change can expose this on LoongArch64 when .text
and .data are linked with 0x1000 alignment while .hii still keeps a
0x4000 alignment. GenFw then keeps a 0x4000 PE/COFF section alignment
because of .hii, producing different ELF and PE/COFF layouts.
Fix two LoongArch relocation paths exposed by this layout mismatch.
R_LARCH_64 entries stored in section contents, such as switch jump
tables, must be translated from the linked ELF section address space to
the generated PE/COFF RVA space. R_LARCH_PCALA_* and R_LARCH_GOT_PC_*
must also convert the referenced symbol to its generated PE/COFF RVA
before calculating the PC-relative offset.
The LoongArch ELF ABI defines PCALA/GOT_PC relocations as page-based,
but this GenFw path rewrites the HI/LO pair to PCADDU12I plus ADDI.D.
After that rewrite, the offset split must be based on the generated
PE/COFF instruction-relative offset.
For example, in the failing LogoDxe image, _gUefiDriverRevision is at
ELF address 0x5400 in .text, and the relocation referencing it is at ELF
address 0x104c. With ELF .text at 0x1000 and PE/COFF .text at 0x4000,
the generated PE/COFF RVAs are 0x8400 for the symbol and 0x404c for the
relocation site. Mixing the ELF symbol address with the PE/COFF
relocation-site RVA makes the entry wrapper read PE/COFF RVA 0x5400
instead of 0x8400, causing EFI_INCOMPATIBLE_VERSION.
Use PE/COFF RVAs consistently when rewriting LoongArch absolute and
PC-relative references during WriteSections64(). The existing
WriteRelocations64() base relocation emission is kept for load-time
image rebasing.
Reported-by: Chao Li <lichao@loongson.cn>
Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
Signed-off-by: Chao Li <lichao@loongson.cn>
Tested-by: Dongyan Qian <qiandongyan@loongson.cn>
The relocation methods of R_LARCH_PCALA_HI20, R_LARCH_PCALA_LO12,
R_LARCH_GOT_PC_HI20 and R_LARCH_GOT_PC_LO12 have been optimized to
support cases where HI is not adjacent to LO and where one HI
corresponds to multiple LOs.
Signed-off-by: Chao Li <lichao@loongson.cn>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Guillermo Antonio Palomino Sosa <guillermo.a.palomino.sosa@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Cc: Poncho Figueroa <poncho.figueroa.esqueda@intel.com>
Cc: Mike Beaton <mjsbeaton@gmail.com>
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>
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 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>
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 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>
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>
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>
Update _get_win32_parent_processes() to detect a
cycle in parent process ids that can cause
_get_win32_parent_processes() to never return.
If a pid cycle is detected, then return the list
of parent process ids detected up to the point
the cycle is detected.
GitHub Actions builds using windows-2025 can
reproduce this issue once in a while. It shows
up as job that runs until a timeout. If the job
is canceled, the logs show a python stack in the
loop in _get_win32_parent_processes().
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
The ELF psABIs for all architectures stipulate that R_*_NONE relocations
require no action at relocation time, and merely exist to declare a
dependency on a symbol in a way that cannot be conveyed by the code
itself (i.e., using an actual symbol reference). Given that EFI PE/COFF
images are always fully linked binaries, such a dependency cannot be
translated, and there are no known reasons why this would be necessary.
So instead of ignoring such relocations specifically on x86_64 only,
ignore them on all architectures when converting ELF binaries to
PE/COFF.
Fixes: #11878
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
For nebulous reasons, the original ELF psABI deviated from common sense,
and decided to #define R_AARCH64_NONE as '256', in spite of the fact
that no other architecture uses anything other than 0x0.
This has now been fixed in the psABI, so fix it in our code as well.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
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 <michael.d.kinney@intel.com>
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 <mjsbeaton@gmail.com>
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 <null>, this achieves the same safely.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
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 <mjsbeaton@gmail.com>
When traversing through the field definition of a nested type, such
as "MY_EFI_BITS_VARSTORE_DATA.BitsData.NestBitCheckbox", in method
CVfrVarDataTypeDB::GetDataFieldInfo, the mBitWidth member of the
parent (e.g. BitsData) of a bitfield is accessed, even though it
is not itself a bit field and thus its mBitWidth has never been
initialised.
This is not necessary, the Size and Type of each parent object
were being calculated then overwritten by the next lower object,
so we can just avoid calculating these until the final one which
we actually need.
This behaviour was caught by clang MSan.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
The memmove in SetClassGuid at line 684 generates a
`store to misaligned address` runtime warning when
VfrCompile is compiled with clang UBSan.
We can avoid generating code which stores to a misaligned
address in a least a couple of other ways than done here,
including casting the destination pointer of the memmove
to (VOID *), or compiling with `-fno-builtin-memmove`.
However, maintaining an unaligned pointer to an aligned
type is, strictly speaking, undefined behaviour in the
c/c++ standard (regardless of how it is or is not then
accessed).
So here we resolve the actual incorrect semantics of this
part of the code (and thereby fix the unaligned access) by
introducing a PACKED_EFI_GUID type in VfrUtilityLib.h, and
using it for this unaligned access.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
Using GCC 13.3.0 discovers an out of bounds memory access in VfrCompile
when building DriverSampleDxe. This is also discoverable with ASan.
The issue here is that EFI_IFR_TYPE_VALUE is a flexible type and
when passed by value for string types only the header part is accessible.
Assuming the remainder is zero seems to be ok as gZeroEfiIfrTypeValue
is used as a variable source.
This change also fixes a warning for new[]/delete[] mismatch
discovered by ASan.
Co-authored-by: Vitaly Cheptsov <vit9696@protonmail.com>
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
Without this change, the macro causes unwanted 'member access within
null pointer' warnings with UBSan.
This is the same macro definition as used in MdePkg/Include/Base.h,
except for removing the legacy `__GNUC__ >= 4` test. Ideally the
orginal macro should have this removed too, as should the several
other instances with similar tests around the codebase, but we leave
that for a separate commit.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
Add newlines to the error messages in GnuMakeUtils. writelines function
does not add newlines automatically so the print is merged with a line
that is printed next.
Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
Update the brotli submodule to the commit (e230f474).
to avoid build failures in the IA64/LoongArch architecture's
native compiler.
The fundamental reason is that GCC does not support the
__attribute__((model("small"))).
REF:https://github.com/google/brotli/pull/1369
Suggested-by: MingcongBai <jeffbai@aosc.io>
Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
# Description
Update brotli from v1.0.9 to v1.2.0
https://github.com/google/brotli/releases/tag/v1.2.0
- [ ] Breaking change?
- **Breaking change** - Does this PR cause a
break in build or boot behavior?
- Examples: Does it add a new library class
or move a module to a different repo.
- [x] Impacts security?
- **Security** - Does this PR have a direct security impact?
- Fixes CVE-2025-6176 reported in brotli < 1.2.0.
- [ ] Includes tests?
- **Tests** - Does this PR include any explicit test code?
- Examples: Unit tests or integration tests.
## How This Was Tested
Verified booting on a virtual platform by
compressing/decompressing PEI/DXE sections.
## Integration Instructions
NA
Signed-off-by: Vineel Kovvuri[MSFT] <vineelko@microsoft.com>
Parse the ELF file for RISC-V Zicfilp extension support to identify
forward control flow integrity (FCFI) features.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
The DXE_SAL_DRIVER module type was introduced to support
Itanium (IPF) platforms. Since support for Itanium processors has been
dropped, the instances of DXE_SAL_DRIVER have been removed.
Ref: [3cb0a311cb]
Cc: Sachin Ganesh <sachinganesh@ami.com>
Signed-off-by: Sathya Ravichandran <sathyar@ami.com>
Building the C BaseTools using Clang on a Windows system that has the Python
interpreter installed to a path that contains spaces (for example
C:\Program Files\Python314\python.exe) currently fails.
This change adds quoting to fix that issue.
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Add --image-version option that takes a version value
of the form MMMM.mmmm where MMMM and mmmm are decimal
values < 65536. The MMMM and mmmm values are used to
set the PE/COFF optional header fields MajorImageVersion
and MinorImageVersion.
If MMMM or mmmm are larger than 65535, then generate
Error() condition.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
When --prm is specified, a search for the symbol with the
name PRM_MODULE_EXPORT_DESCRIPTOR_NAME is performed. If
the symbol is not found, then GENFW generates an exception
due to a loop with a terminal count of -1.
Update logic to not search for PRM Handler symbols if the
PRM_MODULE_EXPORT_DESCRIPTOR_NAME was not found and add
an Error() message when --prm is specified and
PRM_MODULE_EXPORT_DESCRIPTOR_NAME was not found.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
edk2 is dropping support for the ARM32 architecture. This
commit removes ARM32 code from BaseTools.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
The register keyword was deprecated in C++11 and removed in C++17,
which causes multiple compiler warnings when building VfrCompile:
"ISO C++17 does not allow ‘register’ storage class specifier".
Resolve the warnings by removing instances of register keyword.
Signed-off-by: Vishal Oliyil Kunnil <vishalo@qti.qualcomm.com>
It's illegal that string default is numeric type in vfr string definition.
This patch add a check to the illegal behavior. If numeric string default
is encountered, throw a invalid parameter error to break VfrCompile.
Cc: Chao Li <lichao@loongson.cn>
Signed-off-by: Gao Qihang <gaoqihang@loongson.cn>
The Universal Graphics Adapter (UGA) is a graphic abstraction.
The UGA I/O and Draw protocols are deprecated since UEFI 2.0 was
introduced. Cf. the UEFI spec v2.9:
"Appendix L - EFI 1.10 Protocol Changes and Deprecation List"
section L.2 "Deprecated Protocols"
Remove the UGA support.
Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Building .aslc files in a module for host-based unit
testing in Linux/GCC X64 environments may introduce
relocations for a symbol in a shared library from
lcov or asan.
Update logic to not generate an error message and exit
if the symbol is unknown but the relocation type is
R_X86_64_NONE.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Adds support for building the C language BaseTools for Windows using
toolchains based on mingw-w64.
Mingw-w64 is a collection of header files, libraries, and tools that
when combined with a compiler enable development of Windows software.
Mingw-w64 is a fork of the original MinGW (Minimalist GNU for Windows).
Most active development on MinGW has ceased and mingw-w64 is now the
actively maintained successor. Mingw-w64 provides a libc implementation
built on top of Microsoft's UCRT (Universal C Runtime) with all
nessesary compiler bindings needed to support the C++11 feature set.
Modern mingw-w64 development appears to have coalesced around MSYS2,
which produces a distributions of both GCC and LLVM/Clang that use
mingw-w64 to target the Windows OS. This MSYS2 Clang distribution has a
UNIX-like directory layout and includes Windows binaries of GNU Make.
Combined with the open source licensing, MSYS2's Clang distribution is a
highly attractive choice as an alternative Windows SDK for open source
projects such as TianoCore.
If one wishes to use EDK II to build UEFI firmware on the Windows
platform, then the C BaseTools need to be compiled as Windows
applications. This includes the PcdValueInit.exe program, which needs
to be recompiled every time a firmware build is run in order to
regenerate the initial values for structured PCDs. Currently, BaseTools
only supports the Visual C++ toolchain on the Windows platform. The
following new features have been added to enable usage of the toolchains
derived from mingw-w64:
- Fixes to the BaseTools C source code to support the use of a
GCC-style compiler on the Windows OS.
- The GNU Make-style Makefiles for the C BaseTools have been modified
to support Windows. Both GCC + mingw-w64 and Clang + mingw-w64 have
been tested and confirmed to build a working BaseTools.
- BaseTools now supports generating GNU Make-style Makefiles on the
Windows platform for the purpose of building firmware.
- edksetup.bat has been modified to optionally build BaseTools via
mingw-w64. There is no impact to the existing support for Visual C++
and Visual C++ remains the default toolchain.
Usage Instructions:
For the vast majority of users, the only system setup change nessesary
to use a mingw-w64 toolchain is to set the BASETOOLS_MINGW_PATH to the
directory containing the desired mingw-w64 based toolchain.
A new command line argument has been added to edksetup.bat: Mingw-w64
If this command line argument is set, then the script will set the
BASETOOLS_MINGW_BUILD environment variable. The user can also opt to set
this environment variable manually before running edksetup.bat
If BASETOOLS_MINGW_BUILD is defined, then the BASETOOLS_MINGW_PATH
environment variable must point to the directory containing the
mingw-w64 toolchain.
If CLANG_BIN is not defined and %BASETOOLS_MINGW_PATH%\bin\clang.exe
exists, then edksetup.bat will set CLANG_BIN=%BASETOOLS_MINGW_PATH%\bin\
This removes the requirement to configure the CLANG_BIN environment
variable manually in order to run a CLANGPDB or CLANGDWARF build if one
has the MSYS2 Clang distribution installed. If one wishes to use a
different copy of Clang (for example official LLVM binaries) to build
firmware and only use the MSYS2 Clang to build BaseTools, then one can
continue to set the CLANG_BIN environment variable, same as before. I
have tested the MSYS2 Clang distribution against the official LLVM
distribution and can confirm that if the compiler version is the same
the emitted machine code is identical between the two. Interestingly,
the MSYS2 Clang distribution emits the path to the PDB file using "/" as
the path seperator instead of "\". That appears to be the only
difference in output. Therefore, using the MSYS2 Clang distribution to
compile firmware seems a reasonable choice.
If CLANG_HOST_BIN is not defined and BASETOOLS_MINGW_BUILD is defined
and %BASETOOLS_MINGW_PATH%\bin\mingw32-make.exe exists, then
edksetup.bat will add %BASETOOLS_MINGW_PATH%\bin\ to the PATH and set
CLANG_HOST_BIN=mingw32-
This enable usage of the GNU Make included in the mingw-w64 toolchain
to build firmware in addition to BaseTools. if BASETOOLS_MINGW_BUILD is
not defined, edksetup.bat will continue to set CLANG_HOST_BIN=n, which
uses nmake to build firmware. This behavior can be overridden by
manually setting the value of CLANG_HOST_BIN before executing
edksetup.bat if one wishes to use a specific Make utility for the
CLANGPDB/CLANGDWARF toolchains.
References:
- https://www.mingw-w64.org/
- https://www.msys2.org/
Co-authored-by: Sandesh Jain <sandesh.jain@intel.com>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
This change adds support for GCC-style preprocessor line
directives as documented in:
https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html
On Windows systems, one can use line-markers to see which .vfr
file was used to generate a *.i file in the Build directory.
This is useful for debugging VFR compilation failures.
With this change, the VfrCompiler will not generate compilation
errors if the *.i file contains GCC-style line-markers. Without
this change, one must disable the pre-processor's emission of
line-markers, removing the debug aid they provide.
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
In case of the FV with VTF, the left size should be enough to add the
minimum pad file size (EFI_FFS_FILE_HEADER, 0x18). It prevents the build
error, "GenFv: ERROR 0006: invalid FFS file header checksum" caused by the
pad file overwriting some header data in VTF. This includes these updates
for CalculateFvSize() function.
1. If NumBlocks is not defined, ensure the minimum pad file size for the
left size (if the pad file is required as VTF is not bottom aligned at end
of block, insert EFI_FFS_FILE_HEADER to ensure the pad file size)
2. If NumBlocks is defined, report more clear error message (the required
fv image size = 0x%x. the set fv image size = 0x%x. Free space left is not
enough to add a pad file (0x18))
3. Remove MaxPadFileSize, which is reported when the taken size is same as
the total size. It can not be the actual left size to add an FFS file. It
causes confusion when referring to the build log (FV Space Information)
Signed-off-by: Phil Noh <Phil.Noh@amd.com>
Add /wd4200 to all visual studio builds of C tools in BaseTools.
This disables warnings for use of flexible array members that
are allowed in edk2 include files. Some tools use include files
from MdePkg that use flexible array members.
This matches the warning disables used to build structured PCD in
BaseTools/Source/Python/Workspace/DscBuildData.py where flexible
array members are more widely used.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
The prehistoric code base doesn't build with ISO C23. Set the C
standard to C11 (for both clang and gcc) so it continues to build with
gcc 15 (which uses C23 by default).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
