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>
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>
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>
Add quotes around the OBJCOPY command in build_rule.template to fix the
case where LLVM is installed on Windows in a path with spaces such as
C:\Program Files\LLVM.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
EDKII build system supports OptionROM generation if particular PCI_*
defines are present in the module INF file:
```
[Defines]
...
PCI_VENDOR_ID = <...>
PCI_DEVICE_ID = <...>
PCI_CLASS_CODE = <...>
PCI_REVISION = <...>
```
Although after the commit d372ab585a2cdc5348af5f701c56c631235fe698
("BaseTools/Conf: Fix Dynamic-Library-File template") it is no longer
possible.
The build system fails with the error:
```
Cyclic dependency detected while generating rule for
"<...>/DEBUG/<...>.efi" file
```
Remove "$(DEBUG_DIR)(+)$(MODULE_NAME).efi" from the 'dll' output files
to fix the cyclic dependency.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Prior to this change, deps were not generated for Arm and AARCH64
libraries when MODULE_TYPE was BASE, SEC, PEI_CORE, or PIEM. That
resulted in bad incremental builds.
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Fix gcc: warning:
-x c after last input file has no effect
These kind of flag can only affect the source code after them.
For the build command in build_rule.template, we have no other source code or object after these two flag.
It seems we don't need them here.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: JessyX Wu <jessyx.wu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
RVCT is obsolete and no longer used.
Remove support for it.
Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
In the Dynamic-Library-File template, add missing output file
declarations. These files are generated by the template and other rules
explicitly depend on them.
This change resolves missing dependency issues we encountered while
running a recursive make with job control.
Signed-off-by: Jake Garver <jake@nvidia.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3810
New macro OBJCOPY_STRIPFLAG is added in build_rule.template to replace
'--strip-unneeded -R .eh_frame', so that module can have some unique
objcopy flags for its own purpose.
In tools_def.template, set '--strip-unneeded -R .eh_frame' as default
value of OBJCOPY_STRIPFLAG.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
LLVM/CLANG doesn't support resource section generation when ELF image generated.
Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Feng Bob C <bob.c.feng@intel.com>
The AmlToHex script and Posix/WindowsLike wrappers convert
an AML file to a .hex file, containing a C array storing
AML bytecode. This ".hex" file can then be included in a
C file, allowing to access the AML bytecode from this C
file.
The EDK2 build system doesn't allow to a depict dependency
orders between files of different languages. For instance,
in a module containing a ".c" file and a ".asl", the ".c"
file may or may not be built prior to the ".asl" file.
This prevents any inclusion of a generated ".hex" in a
".c" file since this later ".hex" file may or may not
have been created yet.
This patch modifies the AmlToC script to generate a C file
instead of a ".hex" file.
It also adds the generation of an intermediate ".amli" file
when compiling an ASL file, and adds a rule to convert this
".amli" to a C file.
This allows to generate a C file containing the AML bytecode
from an ASL file. This C file will then be handled by the EDK2
build system to generate an object file.
Thus, no file inclusion will be required anymore. The C file
requiring the AML bytecode as a C array, and the ASL file,
will be compiled independently. The C array must be defined
as an external symbol. The linker is resolving the
reference to the C array symbol.
To summarize, the flow goes as:
-1. ASL file is compiled to AML;
-2. AML file is copied to a ".amli" intermediate file;
-3. EDK2 build system applies the rule relevant to ".amli"
files. This is, calling the "AmlToC" script, generating
a C file from the ".amli" file;
-4. EDK2 build system applies the rule relevant to C files.
This is creating an object file.
-5. EDK2 build system links the object file containing the
AML bytecode with the object file requiring it.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Suggested-by: Tomas Pilar <Tomas.Pilar@arm.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The "-tc" option of the iasl compiler allows to generate a
.hex file containing a C array storing AML bytecode.
An online discussion suggested that this "-tc" option
was specific to the iasl compiler and it shouldn't be relied
on. This conversation is available at:
https://edk2.groups.io/g/devel/topic/39786201#49659
A way to address this issue is to implement a compiler
independent script that takes an AML file as input, and
generates a .hex file.
This patch implements a Python script that converts an AML
file to a .hex file, containing a C array storing AML bytecode.
This scipt has been tested with the AML output from the
following compilers supported by the EDKII implementation:
* Intel ASL compiler
* Microsoft ASL compiler
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2311
Enable the dependent files generation function for compilers
and Trim tool.
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2341
Based on feedback from https://edk2.groups.io/g/devel/message/50466,
CLANGPDB is the most acceptable tool chain name,
because this tool chain generates PE/COFF image with PDB debug symbol.
The following changes are made in this patch.
1. Update tool chain name from CLANG9 to CLANGPDB.
2. Update tool chain BUILDRULEFAMILY from CLANGPE to CLANGPDB.
3. Update CLANG9_BIN env name to CLANG_BIN without version info.
Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
It can be used to indicate a module can be build to run
as OS application and run in OS environment.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1450
In the Multiple thread Genfds feature, build tool generates
GenSec, GenFFS command in Makefile.
The Non-Hii Driver does not generate .offset file for uni string offset,
but the build tool has not knowledge about this in autogen phase. So
in this patch, I add a check in Makefile for GenSec command. If the GenSec
input file does not exist, the GenSec will not be called. And if GenSec
command is not called, its output file, which is also the input file of
GenFfs command, will also not exist.So for GenFfs command,
I add a new command parameter -oi which means
the input file is an optional input file which would not exist. so
that I can generate GenFfs command with "-oi" parameter in Makefile.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Update aslc rule to rename the temp output file from .efi to .pecoff.
This change can avoid the conflict .efi file name in output directory.
One is the driver image, another is aslc temp output file.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
We met a case on GCC toolchain for increment build. the case is user
build Helloworld first, then rename the source file Helloworld.c to
Helloworld_new.c and also update the file name to Helloworld_new.c in
.inf file's [sources] section. finally, he rebuild it again.
It cause build failure due to multiple definition of `UefiMain' because
in the .lib file it both have Helloworld.obj and Helloworld_new.obj.
current we use the option 'cr' to create the .lib file while the 'r'
cmd means replace existing or insert new files into the archive. so
in this patch before we create the .lib file, we delete it first.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Build options for ARM64 are the same as for ARM, except for /BASE:0
which is removed from DLINK flags to avoid LNK1355 error:
invalid base address 0x0; ARM64 image cannot have base address below 4GB
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Clang's preprocessor behaves differently from GCC's, and produces
intermediate device tree source that still contains #pragma pack()
and other directives that the device tree compiler chokes on.
For assembling device tree sources, it matters very little which
preprocessor is being used, so let's just use GNU CPP explicitly.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
We duplicate the Assembly-Code-File section from build_rule.template
because --convert-hex cannot be used with the MSFT ARM assembler.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>
By default, the device tree compiler emits phandle properties twice:
once called 'phandle' and again called 'linux,phandle'. Given that
Linux was updated in early 2010 [0] to accept the former (which is
what is specified in the ePAPR and device tree specifications), there
is no point in emitting both when compiling device trees for UEFI
platforms.
[0] 04b954a673dd02f585a2769c4945a43880faa989
"of/flattree: Make the kernel accept ePAPR style phandle information"
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
While modern AARCH64 server systems use ACPI for describing the platform
topology to the OS, ARM systems and AARCH64 outside of the server space
mostly use device tree binaries, which are compiled from device tree
source files using the device tree compiler.
Currently, such source files and binaries may be kept in the EDK2 platform
trees, but are not integrated with the build, which means they need to be
kept in sync and recompiled manually, which is cumbersome.
So let's wire up BaseTools support for them: add tool definitions for the
DTC compiler and preprocessor flags that allow these source files to use
FixedPcd expressions and other macros defined by AutoGen.h
This way, a device tree binary can be built from source and emitted into
a FFS file automatically using something like:
DeviceTree.inf:
[Defines]
INF_VERSION = 0x00010019
BASE_NAME = SomePlatformDeviceTree
FILE_GUID = 25462CDA-221F-47DF-AC1D-259CFAA4E326 # gDtPlatformDefaultDtbFileGuid
MODULE_TYPE = USER_DEFINED
VERSION_STRING = 1.0
[Sources]
SomePlatform.dts
[Packages]
MdePkg/MdePkg.dec
SomePlatform.fdf:
INF RuleOverride = DTB xxx/yyy/DeviceTree.inf
[Rule.Common.USER_DEFINED.DTB]
FILE FREEFORM = $(NAMED_GUID) {
RAW BIN |.dtb
}
where it can be picked at runtime by the DTB loader that may refer to it
using gDtPlatformDefaultDtbFileGuid.
Note that this is very similar to how ACPI tables may be emitted into a
FFS file with a known GUID and picked up by AcpiTableDxe at runtime.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=582
Don't enable this option in the default setting, because it may cause VS2015
linker crash. Platform can enable this option in PlatformPkg.dsc like below:
[BuildOptions]
*_*_*_DLINK2_FLAGS = /WHOLEARCHIVE
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
BaseTools add support to generating image package from BMP/JPEG/PNG
files.
1) New file type *.idf Image definition file to describe HII image
resource. It is the ASCII text file, and includes one or more "#image
IMAGE_ID [TRANSPARENT] ImageFileName".
2) New IMAGE_TOKEN macro is used to refer to IMAGE_ID.
3) New AutoGen header file $(MODULE_NAME)ImgDefs.h to include the
generated ImageId definition.
4) New $(MODULE_NAME)Idf.hpk or $(MODULE_NAME)Images are generated
as the output binary HII image package.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Commit 478f50990a ("BaseTools GCC: add the compiler flags to the linker
command line") added the compiler flags to the linker command line,
which is required for LTO to function correctly, since it involves code
generation at link time.
This patch failed to update the build rules for XIP modules on AARCH64,
which not only requires the ordinary CC flags but also the XIP CC flags
to prevent the LTO backend to, e.g., emit code that does not adhere to
the strict alignment rules we impose for code that may execute with the
MMU off.
So update the XIP link rules as well. Since AARCH64 and ARM are not
supported by any toolchains in the GCCLD build rule family, drop the
reference to GCCLD while we're at it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Both binutils ar and LLVM ar support "cr", but LLVM ar doens't
support add "-" in the flags, and llvm-ar cannot accept "-cr".
So remove the short dash "-" to make llvm archives work.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi <steven.shi@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Given that we only support ARMv7 and up in Tianocore (due to the fact
that the PI spec mandates that the PEI services table pointer be stored
in the TPIDRURW register, which is not available on earlier CPUs), we can
assume that any code executing with the MMU on may perform unaligned
accesses (since the AArch32 bindings in the UEFI spec stipulate that
unaligned accesses should be allowed if supported by the CPU)
So relax the alignment restrictions to XIP modules only, i.e., BASE, SEC,
PEI_CORE and PEIM type modules, exactly like we do for AARCH64 already.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Now that we invoke GCC as the linker for the GCC toolchain family,
we can pass the CC flags to the linker as well. This is only
required for LTO (which may involve code generation during the link
stage), but does not interfere with non-LTO builds.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
In order to be able to share the compiler flags with the linker (which
is required for LTO since it involves the linker doing code generation
based on the LTO bytecode), move the -c GCC argument to the build rules,
and drop it from the GCC CC_FLAGS definitions in tools_def.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Now that GenFw converts small code model ADRP instructions to ADR on
the fly, we can reduce the alignment for XIP modules, where large
alignment values may cause considerable waste of flash space due to
excessive padding. This limits the module size to 1 MB, but this is
not a concern in practice.
So set the XIP section alignment to 0x20 for DEBUG_GCC49, DEBUG_GCC5
and *_CLANG35, all of which use the small code model.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
To accommodate upcoming GCCx toolchain versions that require 'gcc' to
be used as the linker in order to support LTO, switch GCC44 and later
(including CLANG35) to a new DLINK build rule that invokes 'gcc' as the
linker instead of 'ld'. Since gcc expects its command line arguments in
a different format, and expects arguments that it needs to pass to the
linker to be prefixed with '-Wl,', this involves changes to most of the
DLINK_FLAGS definitions in tools_def.template, as well as some changes to
module .INF files that set their own linker options.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Before we can make non-backward compatible changes to the GCC build rules
regarding the use of the 'gcc' binary as the linker, clone the existing
GCC build rules into a 'GCCLD' build rule family, and move the legacy
toolchains UNIXGCC, CYGGCC, CYGGCCxASL and ELFGCC over to it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
