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 a257988f59 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 14cb48b0a0 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>
These haven't been used since before 2d07607d8b,
when UNIXGCC support was dropped.
The recent change in 14cb48b0a0 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>
$(DEBUG_DIR)/<M>.efi is generated by the recipe of
$(OUTPUT_DIR)/<M>.efi: the .efi file is generated and then copied into
$(DEBUG_DIR). At the moment the generate GNUmakefile does not declare
the dependency between these two files, which can be a problem because
$(FFS_OUTPUT_DIR)/<M>.offset depends on $(DEBUG_DIR)/<M>.efi.
Normally $(DEBUG_DIR)/<M>.efi is generated first and there is no
problem, but when an external tool builds edk2 from a Makefile, like
OP-TEE build does for instance, the parallel '-j' flag passed to Make is
inherited by the edk2 GNUmakefile from the environment. As a result Make
might try to build the $(FFS_OUTPUT_DIR)/<M>.offset target in parallel
and fail to find the .efi file:
make[1]: *** No rule to make target 'Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/NetworkPkg/VlanConfigDxe/VlanConfigDxe/DEBUG/VlanConfigDxe.efi', needed by 'Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/FV/Ffs/E4F61863-FE2C-4b56-A8F4-08519BC439DFVlanConfigDxe/VlanConfigDxe.offset'. Stop.
If we declare the $(DEBUG_DIR) file as output of this rule, then the
generated GNUmakefile will contain the right dependency declaration:
$(DEBUG_DIR)/VlanConfigDxe.efi: $(OUTPUT_DIR)/VlanConfigDxe.efi
and the parallel build will succeed.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
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>
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>
Add Empty_C_File_Host_Application_Build.c to BaseTools/Conf
that is a C source file with only comments that is used to
compile into an OBJ file using CC_FLAGS for a HOST_APPLICATION
module and the OBJ is passed into the VS20xx DLINK action to
provide the context required to select the correct default
windows application libraries.
Update build_rule.template to compile the empty C file and
generate OBJ in the OUTPUT_DIR of the HOST_APPLICATION
component and use the OBJ in the DLINK action.
This simplifies CC_FLAGS and DLINK_FLAGS for all modules
of type HOST_APPLICATION.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
When running the /wholearchive test build, generate the test .dll as a
different filename to prevent the system holding onto the dll file too
long and generating a build error that the actual dll cannot be found.
Remove the temporary file after it was generated because the successful
completion of the link command is the test case.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
It does 3 things:
1. Use separate linker file for clang vs GCC for RISCV64.
2. Use common page size instead of max page to ensure -z option align values are properly applied.
3. Enforce alignment for .entry segment as per -z option.
When we want to have -z option aligned images, clang while
alignes .text and .data segments correctly, .entry segment
is by default not aligned unless explicitly specified.
This patch makes it explicit to clang that entry seg
should also be aligned to requirements. Somehow GCC does not require such explicit
entry. Hence detachiong both ld files.
Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com>
BaseTools has a limitation that modules in FVs that are force rebased
must have the same file and section alignment. This is intended for
XIP modules.
VS2019 and previous VS toolchains did not set 4k section alignment,
but VS2022 does, in order for memory protections to be applied to
images. This causes issues when building SEC and PEI modules on
VS2022 as the file alignment is 0x20 but the section alignment
is 0x1000, so BaseTools will fail to generate the FV. One option
is to set the file alignment to 0x1000 for all of these files, but
that is a large waste of space and is not feasible on some platforms
that have limited flash space. The other option is to selectively
set 0x20 as the section alignment for SEC and PEI modules, which is
the approach GCC ARM/AARCH64 took.
This is only an issue for building 64-bit PEI on x86 currently, as
other architectures are not supported by VS2022 in edk2 yet. For IA32,
the section alignment is set to 0x20 and so it matches the file
alignment, however x64 PEI uses the X64 DLINK flags which have 0x1000
set. For other architectures that don't have the PEI/DXE architecture
split, this is also an issue.
This commit is required to use VS2022 as the default CI in edk2, as
OvmfPkgX64.dsc will fail to build. Any platform with 64-bit PEI also
requires this.
This commit also updates CryptoPkg.dsc and SecurityPkg.dsc as they
are setting custom section alignments.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
VS2022's DLINK2_FLAGS (containing only /WHOLEARCHIVE) was commented
out during upstreaming, due to some downstream platform issues
when /WHOLEARCHIVE was set. This does not prove an issue for edk2
and is what is used for earlier versions of VS, so is added here
for VS2022.
If platforms see issues, bugs should be filed on edk2 (or fixed in
the platform if applicable).
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
Subsequent to updating the 'null' DEBUG macro to explicitly
discard its expression, it is possible to remove this warning
suppression from CLANGDWARF and still successfully compile
its RELEASE build.
Note that CLANGPDB did and does not have this warning suppressed,
and so before updating the 'null' DEBUG macro, CLANGPDB RELEASE
was not building successfully in recent versions of clang,
but was stopping with the error:
.../edk2/OvmfPkg/VirtioSerialDxe/VirtioSerial.c:28:22: error:
variable 'EventNames' is not needed and will not be
emitted [-Werror,-Wunneeded-internal-declaration]
STATIC CONST CHAR8 *EventNames[] = {
^
This change makes the two CLANG variants match with respect
to this warning, and leaves the warning enabled which is
considered a benefit as it has the potential to catch real
coding errors
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
Clang insists on emitting a movt/movw pair into the function
pro/epilogues to load the stack protector reference value from memory,
and this movt/movw pair may turn out non-consecutively in the
instruction stream.
The resulting symbol reference cannot be fixed up by GenFw, as PE/COFF
always treats movt/movw as a pair, and the ELF-to-PE conversion will
therefore fail.
Just disable the stack protector when using CLANGDWARF.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Starting with Visual Studio 2019 version 16.10, the /volatileMetadata
option is enabled by default when generating x64 code.
This patch disables the /volatileMetadata option for x64 builds in both
VS2019 and VS2022.
We observed a slight increase in used space for the Firmware volumes in
VS2019. Upon investigation, we found that VS2019 version 16.10 enabled
this feature by default. Disabling /volatileMetadata helps reduce the
used space by approximately 3.5KB by considering the 2 Firmware volumes
(2KB uncompressed FV and 1.5KB of compressed FV)
Signed-off-by: Ashraf Ali <ashraf.ali.s@intel.com>
Start the build with TOOL_CHAIN_TAG VS2015 by launch:
Build -t VS2015
ERROR: Would get following build error message:
'c:\Program' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: '"c:\Program Files\Windows Kits\8.1\bin\x86\\rc.exe' : return code '0x1'
Stop.
Fix the build error,
Tested :
TOOL_CHAIN_TAG = VS2015 (>Build -t VS2015)
TOOL_CHAIN_TAG = VS2015x86 (>Build -t VS2015x86)
Signed-off-by: wilson_chen <wilson_chen@phoenix.com>
GCC5 and CLANGDWARF for IA32/X64 use -Os or -Oz as the optimization
level, which agressively optimizes for the smallest possible object
code.
On AARCH64, RISCV64 and ARM, we use -O3 instead, which results in
considerable image bloat, to the point where the Raspberry Pi 4 build in
edk2-platforms does not even build with -D SECURE_BOOT_ENABLE.
So let's align CLANGDWARF across all architectures, and use -Oz
throughout.
Note that O3 is still used for the linker, which build in LTO mode and
therefore performs some code generation as well. This is deliberate: LLD
does not support the Os/Oz optimization levels at all, and using Oz for
the compile pass is sufficient to reduce the code size substantially.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
This patch moves GnuNoteBti.bin from ArmPkg to BaseTools as it
is used during the build by GCC. This removes an unnecessary
dependency on ArmPkg from BaseTools and keeps build related
files in BaseTools.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
This moves the GccLto files from ArmPkg to BaseTools as they
are files that are only used in the build. This removes an
artificial dependency on ArmPkg from BaseTools and keeps build
related files in BaseTools.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Static relocation types have been handled in GenFw if using the PIC, and
the CC flags not enable `fno-pic` by default.
The option `fno-plt` is not necessary, as is not created by defualt in
edk2(static linking) regardless of wether `fplt` is used or not, so
remove this option from the LoongArch common CC flags.
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Adding tools_def for VS2022.
Update WindowsVsToolChain to support VS2022.
Update set_vsPrefix_envs and toolsetup and edksetup to support VS2022.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
The warnings Clang emits when enabling -Wunneeded-internal-declaration
(which is part of -Wall) are generating false positives for variables
whose size gets taken but are not referenced beyond yet.
This may happen legitimately in debug code, so let's disable this
warning for Clang, rather than tiptoe around it in the code.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
When using CLANGDWARF to build for the ARM architecture, objcopy is
references via the wrong environment variable, resulting in the wrong
llvm-objcopy to be used (if one exists), or the build to fail (if
CLANGDWARF_BIN points to the only available instance)
So use CLANGDWARF_BIN instead, which was what was intended.
Fixes: ecbc394365 ("BaseTools: Set CLANGDWARF RC path ...")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
This reverts commit 11f62f4cc0.
While GCC uses objcopy for the OBJCOPY command, it's not needed for the
CLANGDWARF toolchain and can be left as echo.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Ard BIesheuvel <ardb@kernel.org>
The build rule for Hii-Binary-Package.UEFI_HII should be the same as for
GCC, using $(RC) to embed the HII resource into the binary. Since the
build rule defaults to GCC, just remove CLANGGCC from the section.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
The llvm-rc tool is for Windows PE resources. Since the CLANGDWARF
toolchain creates ELF binaries, update the RC path to be llvm-objcopy.
This follows the GCC toolchain which uses objcopy for the RC path.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
There's only a single rule in build_rule.template for CLANGGCC, and it's
incorrect. We should instead just use the rules for GCC, so remove the
BUILDRULEFAMILY line for the CLANGDWARF toolchain definition.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
Clang 3.8 is a very old release and is no longer relevant. Delete the
CLANG38 toolchain from tools_def.template.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
Clang 3.5 is a very old release and is no longer relevant. Remove the
CLANG35 toolchain from tools_def.template.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
As with the IA32 and X64 CLANGDWARF toolchain definitions, use ld.lld
for ARM and AARCH64.
Add -Wl,--no-pie,--no-relax to the command line to fix linking when
using lld.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
