This produces output that matches CodeChecker log command
- Set directory to build output path
- Set build destination to the object created instead of the path
- Add recursive macro support
- Add lookup in module.Macros dictionary
- Add leading include flag to include list
- Add source file to compile commands
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
When collecting the required library instances for modules and
libraries, included libraries will be recursed to ensure the module is
built with all the libraries directly linked to it and indirectly
linked to it via included libraries.
Using the following scenario as an example:
[LibraryClasses.common.DXE_CORE]
NULL|Path/To/Library1.inf // Includes DebugLib
[LibraryClasses.common.DXE_DRIVER]
NULL|Path/To/Library2.inf // Includes DebugLib
[LibraryClasses.common.DXE_CORE, LibraryClasses.common.DXE_DRIVER]
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
[Components]
MdeModulePkg/Core/Dxe/DxeMain.inf // Includes DebugLib
The DXE_CORE NULL library will be assigned a fake library class like
NULL1 and the DXE_DRIVER will be assigned NULL2. The recursion logic
will see NULL1 as a directly linked and will add an instance of it to
the list of libraries which need to be included in the module. When
DebugLib is evaluated, the recursion logic will add the libraries
DebugLib depends on to the queue which includes both NULL1 and NULL2.
When NULL2 is unqueued, an instance of it will also be added to the
list of libraries needed to build DxeMain which now means that both
NULL1 and NULL2 have been linked.
NULL includes outside of module overrides are not supported according
to the spec, but we do it anyways so this seems like a case which
should be fixed. This change updates the recursion logic to skip
evaluating NULL libraries unless they are linked directly to the
module/library being evaluated.
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: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Bugzilla ticket 4633
FdfParser.py has defined a key named OEM_CAPSULE_FLAGS to set the
lower 16 bits of EFI_CAPSULE_HEADER.Flags. However, this key is totally
"forgotten" in Capsule.py, making it impossible to set lower 16 bits of
this field, and leading to an always FALSE when comparing to
gEfiMdeModulePkgTokenSpaceGuid.PcdSystemRebootAfterCapsuleProcessFlag
in MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleProcessLib.c:
ProcessTheseCapsules().
This patch ORs the value of OEM_CAPSULE_FLAGS with previously calculated
CAPSULE_FLAGS value, making the lower 16 bits of value being correctly set.
Signed-off-by: Igniculus Fu <igniculus.fu@amd.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Eric Xing <eric.xing@amd.com>
Cc: Abdul Lateef Attar <abdattar@amd.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Currently, if an INF path is an absolute path on Linux (begins with
"/"), the "/" character will be removed. If the path is an absolute
system path, this creates an invalid path.
An example of when this may be an issue is in external dependencies
where an INF is within the external dependency, the `set_build_var`
flag is set, and DSC files refer to files by its build variable
(e.g. `$(SHARED_BINARIES)/Module.inf`). INFs in a binary distribution
like this example may contain a [Binaries] section and refer to
different section files that can be used by a platform to compose an
FFS file. For example, the PE32 (.efi) and DEPEX (.depex) files.
In this case, `$(SHARED_BINARIES)` will be an absolute path to the
ext dep directory and `FfsInfStatement.__InfParse__` will remove the
leading "/" character so the path is invalid.
This change first checks if the absolute path will resolve into the
current workspace. If it does (as will happen in the shared crypto
ext dep example above), it modifies the path to be relative to the
workspace so later logic dependent on relative paths can operate on
it. If the absolute path is not within the current workspace, it
follows previous behavior for backward compatibility to that
scenario.
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: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Most module types have standardized entry point function prototypes. They
are declared in headers like
- MdePkg/Include/Library/PeiCoreEntryPoint.h
- MdePkg/Include/Library/PeimEntryPoint.h
- MdePkg/Include/Library/DxeCoreEntryPoint.h
- MdePkg/Include/Library/UefiDriverEntryPoint.h
- MdePkg/Include/Library/UefiApplicationEntryPoint.h
These header files also declare matching ProcessLibraryConstructorList()
prototypes.
The SEC module type does not have a standardized entry point prototype
(aka parameter list), therefore no header file like the above ones exists
for SEC. Consequently, no header file *declares*
ProcessLibraryConstructorList() for SEC modules, even though AutoGen
always *defines* ProcessLibraryConstructorList() with the same, empty,
parameter list (i.e., just (VOID)).
The lack of a central declaration is a problem because in SEC code,
ProcessLibraryConstructorList() needs to be called manually, and those
calls need a prototype. Most SEC modules in edk2 get around this by
declaring ProcessLibraryConstructorList() manually, while some others use
an incorrect (PEIM) prototype.
Liming suggested in
<https://bugzilla.tianocore.org/show_bug.cgi?id=991#c2> that AutoGen
provide the declaration as well; implement that in this patch.
Mike suggested that the feature be gated with INF_VERSION, for
compatibility reasons. (INF_VERSION >= 1.30) reflects that the latest
(draft) version of the INF specification, as of this writing, is commit
a31e3c842bee / version 1.29.
For example, if we modify "OvmfPkg/Sec/SecMain.inf" as follows:
> diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf
> index 3c47a664a95d..dca932a474ee 100644
> --- a/OvmfPkg/Sec/SecMain.inf
> +++ b/OvmfPkg/Sec/SecMain.inf
> @@ -8,7 +8,7 @@
> ##
>
> [Defines]
> - INF_VERSION = 0x00010005
> + INF_VERSION = 1.30
> BASE_NAME = SecMain
> FILE_GUID = df1ccef6-f301-4a63-9661-fc6030dcc880
> MODULE_TYPE = SEC
then the patch produces the following difference in
"Build/OvmfX64/NOOPT_GCC5/X64/OvmfPkg/Sec/SecMain/DEBUG/AutoGen.h":
> --- AutoGen.h.orig 2024-02-06 23:10:23.469535345 +0100
> +++ AutoGen.h 2024-02-07 00:00:57.361294055 +0100
> @@ -220,6 +220,13 @@
>
> // Definition of PCDs used in libraries is in AutoGen.c
>
> +// ProcessLibraryConstructorList() declared here because SEC has no standard entry point.
> +VOID
> +EFIAPI
> +ProcessLibraryConstructorList (
> + VOID
> + );
> +
>
> #ifdef __cplusplus
> }
which presently (as of edk2 commit edc6681206) triggers the following
build error:
> In file included from OvmfPkg/Sec/SecMain.c:14:
> MdePkg/Include/Library/PeimEntryPoint.h:74:1: error: conflicting types for
> ‘ProcessLibraryConstructorList’; have ‘void(void *, const
> EFI_PEI_SERVICES **)’ {aka ‘void(void *, const struct _EFI_PEI_SERVICES
> **)’}
> 74 | ProcessLibraryConstructorList (
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from <command-line>:
> Build/OvmfX64/NOOPT_GCC5/X64/OvmfPkg/Sec/SecMain/DEBUG/AutoGen.h:226:1: note:
> previous declaration of ‘ProcessLibraryConstructorList’ with type
> ‘void(void)’
> 226 | ProcessLibraryConstructorList (
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That's a genuine bug in OvmfPkg that needs to be fixed, but we keep
compatibility with existent SEC modules until/unless they upgrade
INF_VERSION to 1.30+.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=991
Suggested-by: Liming Gao <gaoliming@byosoft.com.cn>
Suggested-by: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20240224210504.41873-1-lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
During the Incremental build GenerateByteArrayValue used to generate the
ByteArrayValue even when there is no change in the PCD/VPDs. which is
time consuming API based on the number of PCD/VPDs and SKU IDs.
The optimization is that GenerateByteArrayValue is used to store the
StructuredPcdsData in a JSON file for each of the arch. and during the
Incremental build this API will check, if there is any change in the
Structured PCD/VPDs then rest of the flow remains the same.
if there is no change then it will return the provious build data.
Flow:
during the 1st build StructuredPcdsData.json is not exists,
StructuredPcdsData will be dumped to json file. and it will copy the
output.txt as well.
Note: as the output.txt are different for different Arch, so it will be
stored in the Arch folder.
During the Incremental build check if there is any change in Structured
PCD/VPD. if there is a change in Structured VPD/PCD then recreate the
StructuredPcdsData.json, and rest of the flow remains same.
if there is no change in VPD/PCD read the output.txt and return the data
Unit Test:
Test1: Modified the Structured Pcds default from DEC file. current flow
is executing.
Test2: Override the default value of the PCD from DEC file. current flow
is executing.
Test3: Modified/Override the PCD from DSC file. current flow executing
Test4: Modified/Override the FDF from DSC file. current flow executing
Test5: update the default value from Command Line.current flow executing
Test6: Build without change in PCD in DSC, FDF, DEC and Command Line the
proposed changes will be executing, and the return data remains the same
with and without the changes.
Test7: Build with and without modified the include headers of Structured
PCDs. if there is any change in those Structured PCD header then
current flow will be executed.
With these changes it's helping to save around ~2.5min to ~3.5min of
Incremental build time in my build environment.
Sample PR: https://github.com/tianocore/edk2-basetools/pull/113
Cc: Yuwei Chen <yuwei.chen@intel.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Amy Chan <amy.chan@intel.com>
Cc: Sai Chaganty <rangasai.v.chaganty@intel.com>
Cc: Digant H Solanki <digant.h.solanki@intel.com>
Signed-off-by: Ashraf Ali S <ashraf.ali.s@intel.com>
Reviewed-by: Yuwei Chen <yuwei.chen@intel.com>
The patch "[PATCH v3 1/2] StandaloneMmPkg: Make StandaloneMmCpu driver
architecture independent" (https://edk2.groups.io/g/devel/message/109178)
removed ArmPkg/ArmPkg.dec from the Packages section in the
INF file: StandaloneMmPkg/Drivers/StandaloneMmCpu/StandaloneMmCpu.inf
This change was done as part of making the StandaloneMmCpu driver
architecture independent.
Although this change is correct, it results in a side effect
here some platforms that utilise PCDs declared in ArmPkg.dec are
no longer declared.
An example of this issue can be seen when building
edk2-platforms/Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
$ build -a AARCH64 -t GCC -p Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc
build.py...
/mnt/source/edk2-platforms/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf(23):
error F001: PCD (gArmTokenSpaceGuid.PcdFdBaseAddress) used in
FDF is not declared in DEC files.
As seen above, removing ArmPkg.dec from the Packages section in the
StandAloneMmCpu Driver Inf file triggers build failure.
Although, ArmPkg.dec is included in other Library Instances,
the build system does not include the declarations from
.dec files defined in Library instances.
The build system only includes the PCD declarations from DEC files
that are specified in INF files for Modules (components).
Therefore, extend the build system to include the Packages from
Library Instances so that the PCD declarations from the respective package
DEC files are included.
This patch can be seen on
https://github.com/LeviYeoReum/edk2/tree/levi/2848_dec_check_on_library
Signed-off-by: levi.yun <yeoreum.yun@arm.com>
Tested-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
In https://bugzilla.tianocore.org/show_bug.cgi?id=2842 clang support was
added by having users specify "make CXX=llvm" when building BaseTools.
The Makefile then sees that and sets CC=$(CLANG_BIN)clang and
CXX=$(CLANG_BIN)clang++. That requires that the executables 'clang' and
'clang++' exist and for example aren't named 'clang-17' and
'clang++-17'. Also, it's an unusual way of specifying the compiler,
since many users will expect to be able to override CC and CXX on the
make command line.
Rework the BaseTools Makefiles removing the 'BUILD_' prefix (BUILD_CC
and BUILD_CXX) and using the standard name 'LDFLAGS' instead of
'LFLAGS'. This allows clang to be used by running
'make -C BaseTools CC=clang CXX=clang++'.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2850
Add "-Y REPORT_INFO" option to build command to generate compile
information as part of BuildReport.
This option generates files to be used by external tools as IDE's
to enhance functionality.
Files are created inside build folder:
<Build>/<BuildTarget>/<ToolChain>/CompileInfo
Files created:
* compile_commands.json - Compilation Database. To be used by IDE's
to enable advance features
* cscope.files - List of files used in compilation. Used by Cscope to parse
C code and provide browse functionality.
* module_report.json - Module data form buildReport in Json format.
Signed-off-by: Guillermo Antonio Palomino Sosa <guillermo.a.palomino.sosa@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Currently the PCD values calculated from the expressions have different
formating from the simple byte arrays in AutoGenC.
Example:
The following definition in DEC:
gTokenSpaceGuid.PcdArray|{0x44, 0x33, 0x22, 0x11}|VOID*|0x55555555
gTokenSpaceGuid.PcdArrayByExpression|{UINT32(0x11223344)}|VOID*|0x66666666
Produces these strings in AutoGenC:
<...> _gPcd_<...>_PcdArray[4] = {0x44, 0x33, 0x22, 0x11};
<...> _gPcd_<...>_PcdArrayByExpression[4] = {0x44,0x33,0x22,0x11};
Add missing space character between the array elements to unify PCD value
formatting.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Currently it is not possible to initialize all elements in the
array PCD.
For example, this PCD would result to a build failure:
gTokenSpaceGuid.PcdArray|{0x11, 0x22}|UINT8[2]|0x4C4CB9A3
Correct logical operator in the initialization data size checks to
fix the issue.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Corrently the set of file types for the PIC section contains two
duplicate values.
Replace the duplicate value with the correct one to fix the issue.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
