| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When building a module containing .aslc files on the CLANGDWARF LoongArch64
platform, errors occur because the target and linker are set incorrectly.
Therefore, this patch:
- Add the missing target triplet to ASLCC_FLAGS so ACPI objects are
compiled for LoongArch64 rather than the host architecture.
- Add -fuse-ld=lld to ASLDLINK_FLAGS so linking does not fall back to the
GCC ld, which lacks elf64loongarch support.
Signed-off-by: Qihang Gao <gaoqihang@loongson.cn>
Signed-off-by: Chao Li <lichao@loongson.cn>
|
|
LoongArch64 GCC or CLANG currently does not support the parameter
`-mstack-protector-guard=global`, but if `-fstack-protector` is enabled,
the guard is global.
The `-mstack-protector-guard` may be get supportted in the next GCC
release, possibly GCC17.
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>
|
|
Removes Visual Studio 2017 support from BaseTools. Newer toolchains
(VS2019, VS2022, and VS2026) are supported in its place.
This removes the VS2017 toolchain definitions from tools_def.template,
the VS2017 environment setup logic in toolsetup.bat,
set_vsprefix_envs.bat, and get_vsvars.bat, and the VS2017
configuration in the WindowsVsToolChain build plugin.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
|
|
REF: https://github.com/tianocore/edk2/issues/12490
Removes Visual Studio 2015 support from BaseTools since mainstream
support ended on October 13, 2020 and extended support ended on
October 14, 2025.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
|
|
Switch GCC RISCV builds to use GCC_ALL_CC_FLAGS so that the -Os
compiler flag is applied during compilation.
For RiscVVirt target, this reduces DXEFV size by ~30%.
Signed-off-by: Tuan Phan <tuan.phan@oss.qualcomm.com>
|
|
Commit 87e486f defined a 3.07 version for tools_def.template, but the
version in the file was not updated. This commit updates the version
to 3.07 and includes changes made since 3.06.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
|
|
Added LoongArch64 CLANGDWARF compiler support. It requires the LLVM
version 22.1.0-rc1 or higher.
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 compiling an IA32 .aslc source file that includes Base.h, the GCC
static asserts for fundamental type sizes fail because 64-bit types such
as UINT64 are only 4-byte aligned by default in 32-bit mode. Adding
-malign-double causes the compiler to align 64-bit values on 8-byte
boundaries, matching the alignment assumed by the static asserts.
This fix is applied to the GCC, GCCNOLTO, CLANGPDB, and CLANGDWARF
toolchain IA32 ASLCC_FLAGS entries.
REF: #12517
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
|
|
Signed-off-by: Yang Gang <yanggang@byosoft.com.cn>
|
|
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>
|
|
StandaloneMm is loaded failure when it built with clang-22.
This is because mMmMemoryMap is intialised incorrectly by compiler:
MmMain - 0xFF025040
[StandaloneMmMain:849] mMmMemoryMap: 0xFF21D238
[StandaloneMmMain:850] mMmMemoryMap->ForwardLink: 0xFF201000
[StandaloneMmMain:851] mMmMemoryMap->BackLink: 0xFF201000
The 0xFF20100 is loaded image address. However list_head -- mMemoryMap
doesn't initialised properly by ld-lld.
Here, ld with gcc initialised mMmMemoryMap list head properly:
// 0x12490: &mMmMemoryMap
# hexdump -Cv -s 0x12490 -n 64 StandaloneMmCore.efi
00012490 90 24 01 00 00 00 00 00 90 24 01 00 00 00 00 00 |.$.......$......|
...
However, ld-lld with clang doesn't:
// 0x1c238: &mMmMemoryMap
# hexdump -Cv -s 0x1c238 -n 64 StandaloneMmCore.efi
0001c238 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
To address this, add --apply-dynamic-relocs linker option.
After this patch, StandaloneMm is loaded preoperly and mMmMemoryMap
is intialised correctly:
ld-lld with clang with --aply-dynamic-reclos option:
// 0x1d238: &mMmMemoryMap
# hexdump -Cv -s 0x1d238 -n 64 StandaloneMmCore.efi
0001d238 38 d2 01 00 00 00 00 00 38 d2 01 00 00 00 00 00 |8.......8.......|
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.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>
|
|
Since
ae83c6b7fd83a5906e016a32027c1bcd792a624e
-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>
|
|
Update version to 3.06 with comment on changes.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
|
|
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
|
|
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>
|
|
* Drop AArch64 definitions
* Drop /ALIGN:32 from X64 linker flags
* Drop ancient EBC compiler information
Signed-off-by: Daniel Grobert <danalexgro@gmail.com>
|
|
Adding tools_def for VS2026.
Update WindowsVsToolChain to support VS2026.
Update set_vsPrefix_envs and toolsetup and edksetup to support VS2026.
Signed-off-by: Daniel Grobert <danalexgro@gmail.com>
|
|
The CLANGDWARF tool chain requires the target to be provided
to both the compiler and linker. Update tools_def.template
to add CLANGDWARF_IA32_TARGET and CLAGDWARF_X64_TARGET to
CLANGDWARF DLINK2_FLAGS. This aligns IA32/X64 with other
CLANGDWARF CPU profiles.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
Update the Hii-Binary-Package rules to use a common rule
for all toolchains except XCODE. This adds GENFWHII_FLAGS
to tools_def.template and supports the use of either a
resource compiler from VS20xx/LLMV or the use of objcopy
for tool chains that do not provide a resource compiler.
There are cases where CLANGDWARF needs to use llvm-rc, so
the same rule must be compatible with objcopy, rc, and
llvm-rc.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
Update CLANGDWARF to work just like GCC for build rules
that convert ELF images to PE/COFF images. This common
build rule uses OBJCOPY. Add OBJCOPY_PATH to CLANGDWARF
for all CPU architectures in tools_def.template.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
Update NASM flags for IA32/X64 in CLANGDWARF and CLANGPDB
tool chains to set the correct NASM options for DEBUG,
RELEASE, and NOOPT profiles.
* NOOPT: Optimizations disabled and generate symbols
* DEBUG: Optimizations enabled and generate symbols
* RELEASE: Optimizations enabled and do not generate symbols
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
Remove -U _MSC_VER from CLANGPDB tool chain in
tools_def.template. _MSC_VER should only be undefined in
specific components that require it to be undefined.
-U _MSC_VER in tools_def.txt for CLANGPDB breaks
host-based unit test builds on Windows.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
Currently, the CLANGDWARF toolchain on AARCH64 fails to pass the
-fuse-ld=lld compiler option, and so linking ACPI table binaries falls
back to the BFD linker. On non-AARCH64 build systems, this will
correctly run the cross-linker, based on the -target argument passed to
Clang, which therefore needs to be installed.
However, the ASLCC invocation fails to pass that same -target argument,
therefore producing object files for the native architecture, which the
cross-linker cannot link, resulting in a build error.
So pass the target in ASLCC_FLAGS as well, which is sufficient to get a
working build. And for good measure, pass -fuse-ld=lld so that we don't
rely on the BFD cross-linker in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
NOOPT_GCC5_LOONGARCH64_CC_FLAGS and NOOPT_GCC_LOONGARCH64_CC_FLAGS were
missing, causing build failures with these toolchains targets to fail.
Add them.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
|
|
It might appear some odd problems if enable GCC relax. Disabling it can
avoid these problems.
Signed-off-by: Chao Li <lichao@loongson.cn>
Cc: Rebecca Cran <rebecca@bsdio.com>
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>
|
|
edk2 is dropping support for the ARM32 architecture. This
commit removes ARM32 code from BaseTools.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
|
|
Update the CLANGPDB toolchain to define the __GNUC__, __GNUC_MINOR__,
__GNUC_PATCHLEVEL__, and __MINGW32__ macros with values that match the
pre-defined values seen when using the x86_64-unknown-windows-gnu target
triple. This minimizes the differences in pre-processor macros between the
CLANGPDB and CLANGDWARF targets.
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
|
|
Remove -nostdlib and -nostdlibinc from CC_FLAGS for CLANG
builds to support using CLANGPDB and CLANGDWARF for modules
of type HOST_APPLICATION that require use of standard C libs.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
All ASM files are processed using PP_FLAGS that includes
AutoGen.h. Remove redundant -imacros AutoGen.h option from
GCC_ASM_FLAGS. This also removes warnings generated in
CLANG builds when an ASM file is processed and an
AutoGen.h file is not present.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
Update ASLCC_FLAGS in tools_def.template too provide all
the options required to compile ACPI Table source files
without any dependencies on CC_FLAGS. This allows CC_FLAGS
to only be used to compile C source files and for
ASLCC_FLAGS to only be used to compile ACPI Tables source
files.
No changes are required for the MSFT or XCODE tool chain
families. Only the GCC tool chain family requires updates
to the ASLCC_FLAGS in tools_def.template along with updates
to build_rule.template to not use CC_FLAGS for ACPI Table
rules.
This change is required to avoid use of ASAN and code
coverage flags when building ACPI Table source files that
break CLANGDWARF builds of ACPI Table source files.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
Add -fno-omit-frame-pointer to RISC-V targets to ensure frame pointers
are preserved, supporting stack backtraces for debugging.
Signed-off-by: Tuan Phan <tphan@ventanamicro.com>
|
|
Commit a257988f590ba90dd8394dd6bc7014ae9d814a08 added -Wl,-z,notext, but
only when linking for IA32/X64 with LLD.
BFD can also be configured to either warn or error when text relocations
are detected. It does not check at all by default, but Gentoo Linux
tells it to warn in its regular configuration and tells it to error in
its hardened configuration.
Commit 14cb48b0a053b44c5a6bcc89cbbbf86ac78c7820 made linker warnings
fatal in all BFD cases. At least the AARCH64 and IA32/X64 code does
include text relocations, so this now fails to build on Gentoo Linux.
We should therefore always use -Wl,-z,notext.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
|
|
For consistency, and as before, for GCC5 only.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
|
|
These haven't been used since before 2d07607d8b1a0710ba7379f8ee6c11dae1,
when UNIXGCC support was dropped.
The recent change in 14cb48b0a053b44c5a6bcc89cbbbf86ac78c7820 to make
linker warnings fatal was therefore ineffective for these architectures.
As requested, also make linker warnings fatal for GCC5 only. The last
release made them fatal for AARCH64 on GCC48/GCC49, but it seems likely
no one has actually tested that yet.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
|
|
Update the CLANGPDB toolchain configuration to use MSVC ABI targets and
retain frame pointers in generated code. This improves compatibility with
the Microsoft Debug Interface Access (DIA) SDK and improves debuggability
with any debugger that uses the Microsoft PDB parser, for example the Visual
Studio debugger or windbg.
Without these changes, code generated by the Clang compiler will have a mix
of calling conventions. With the current configuration, any function declared
with EFIAPI will use the Microsoft x64 calling convention. However, the default
calling convention will be the SysV x64 calling convention. This mixing of
calling conventions prevents debuggers from decoding the call stack.
With these changes, only the Microsoft x64 calling convention will be used.
These modifications enable debuggers to properly parse and
display call stacks on binaries built with the CLANGPDB toolchain.
The changes include:
- Switch from GNU ABI target (*-unknown-windowsl-gnu) to MSVC ABI targets
(*-pc-windows-msvc) for both IA32 and X64 architectures.
- Remove -fseh-exceptions as not supported.
- Add -fno-omit-frame-pointer as required for call stack.
- Undefine the _MSC_VER macro, and define the __GNUC__ macro, so that
pre-processor conditionals will continue to function as expected.
Co-authored-by: Muhammad Mustafa <muhammad.mustafa@intel.com>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
|
|
Alignment needed to be updated to 64 because of a linker warning
when building with MSVC.
/ALIGN:64 is the minimum alignment for MSVC ARM64, which differs from
MSVC x64. This was missed when checking into edk2 because CI isn't
run for MSVC ARM64.
Signed-off-by: Vivian Nowka-Keane <vnowkakeane@linux.microsoft.com>
|
|
/WX was added as a build flag in VS2022 and now aarch64 builds
fail because of an undocumented linker warning: 4226 Alignment specified
exceeds target machine page size.
This linker warning has always occured and can be ignored.
Signed-off-by: Vivian Nowka-Keane <vnowkakeane@linux.microsoft.com>
|
|
This change enables the emission of C preprocessor
line-markers for VFR intermediate files on the GCC and
Clang compilers.
Since the VfrCompiler now supports GCC-style preprocessor
line markers, they can be enabled by default.
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
|
|
VS2019/VS2022 ARM/AARCH64 is not a widely used toolchain, for one
thing edk2 can't be built with it, it will break. Downstream
platforms rarely use it and if they do, they must have heavy edits
in order to support building edk2. In particular, edk2 does not
have support for the assembly files that this toolchain uses fully.
As a result, the corresponding StackCheckLib does not have the assembly
file needed to satisfy the definitions the compiler expects.
Unfortunately, the VS ARM/AARCH64 compiler has a different ABI than
the IA32/X64 VS toolchain for stack cookies, so this also needs more
investigation.
For now, disable stack cookie checking in VS ARM/AARCH64 as this does
not affect many platforms. However, it does allow for the use case
reported in the bug mentioning this, which is building a shell and
attempting to boot to it.
When VS ARM/AARCH64 support is revisited in edk2 (or if there is a
clean way to add stack cookie support without the full support), this
will be revisted.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
|
|
Commit c6f47e6 removed BUILDRULEFAMILY for CLANGDWARF. Adding
CLANGDWARF back as a BUILDRULEFAMILY to match CLANGPDB.
Add CLANGDWARF specific build rules - based on GCC, and remove steps
not required for CLANGDWARF.
Remove following irrelevant steps and logs:
...
"objcopy not needed ..."
"--strip-unneded ..."
"--add-gnu-debuglink ..."
...
Signed-off-by: Vishal Oliyil Kunnil <quic_vishalo@quicinc.com>
|
|
This quiets the warning reported in Issue #10637.
Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
|
|
The linker option 'no-warn-rwx-segments' breaks both the LLVM linker and
versions of the binutils ld.bfd linker prior to 2.39.
Now that the ELF image is made up of separate R-X and RW- segments, this
warning is no longer emitted and so there is no longer a need to
suppress it either.
While at it, move GCC_DLINK_FLAGS_COMMON (which is not common but only
used by Ia32 and X64) into its only user so it can be dropped.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The original reason for creating a separate version of the ELF linker
script for Clang was the difference between COMMONPAGESIZE and
MAXPAGESIZE, which can we provided on the command line to the respective
linkers (ld.bfd versus lld). That difference no longer exists, and both
use COMMONPAGE_SIZE. So there is no longer a need to maintain a fork,
which has already been going out of sync with the original for no good
reason.
So merge the two and call it GccBase.lds
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The command line option --no-warn-rwx-segments was added to the linker
command line for all GCC family builds on ARM and AARCH64, including
CLANGDWARF and GCC49 and older, none of which are intended for use with
linkers that actually understand this option.
So instead, move it to the GCC5 DLINK FLAGS definitions for ARM and
AARCH64 (which are inherited by the versionless GCC which is intended to
replace GCC5 at some point).
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Today VS2022 and GCC are set to treat all compiler warnings as
errors and break the build. However, linker warnings for both
do not break the build. There are critical errors that can be
treated as warnings as the linker, such as not finding the
module entry point and use a default address as the entry
point. This will cause a runtime crash for something that
should be caught at build time.
This commit adds /WX to VS2022's DLINK_FLAGS and --fatal-warnings
to GCC's DLINK_FLAGS for IA32, X64, ARM, and AARCH64 in order to
break the build on linker warnings.
VS2022 linker warning 4210 is ignored for all builds because it
checks for static initializers and the linking of the VCRuntime.
edk2 never links the VCRuntime (except for HOST_APPLICATIONs) and
so the presence of static initializers will always cause this
warning, even when the edk2 code calls these initializers that
would otherwise be called in the _CRT_INIT function of the
VCRuntime. At the time of this commit, it only fails in CryptoPkg
for building OpenSSL, but could fail anywhere a static initializer
is used.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
|
