Tianocore/edk2.git/BaseTools/Source/Python/AutoGen, branch trunk

Renormalized end-of-lines from master@27b044605cd5f6b33a3d231576003850b3fe305b

2024-06-04T03:43:08+00:00

BaseTools/AutoGen: declare ProcessLibraryConstructorList() for SEC modules

2024-02-29T09:56:38+00:00

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 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 edc6681206c1) 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 : > 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 Cc: Liming Gao Cc: Michael D Kinney Cc: Rebecca Cran Cc: Yuwei Chen Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=991 Suggested-by: Liming Gao Suggested-by: Michael D Kinney Signed-off-by: Laszlo Ersek Message-Id: <20240224210504.41873-1-lersek@redhat.com> Reviewed-by: Liming Gao

BaseTools: Remove Duplicate sets of SkuName and SkuId from allskuset

2024-02-08T19:27:18+00:00

Currently when the platform has many SKUs then allskuset will be having so many duplicate. and while parsing the allskuset will take longer time while assigning Pcd.SkuInfoList. This patch is to eliminate those duplicate entries to reduce the build time Cc: Yuwei Chen Cc: Rebecca Cran Cc: Liming Gao Cc: Bob Feng Cc: Amy Chan Cc: Sai Chaganty Signed-off-by: Ashraf Ali S Reviewed-by: Yuwei Chen Reviewed-by: Amy Chan Reviewed-by: Bob Feng

BaseTools: Optimize GenerateByteArrayValue and CollectPlatformGuids APIs

2024-02-08T04:08:38+00:00

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 Cc: Rebecca Cran Cc: Liming Gao Cc: Bob Feng Cc: Amy Chan Cc: Sai Chaganty Cc: Digant H Solanki Signed-off-by: Ashraf Ali S Reviewed-by: Yuwei Chen

Basetools: Include PCD declarations from Library Instance

2024-01-31T10:58:05+00:00

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 Tested-by: Pierre Gondois Reviewed-by: Rebecca Cran Reviewed-by: Sami Mujawar

BaseTools: Fix raw strings containing valid escape characters

2024-01-10T13:54:01+00:00

Fixes raw regex strings that contain valid (and purposeful) escape characters as they are being treated as individual characters rather than the single escaped character they represent (i.e. '\t' is being treated as a '\' and a 't' rather than a single tab character). Signed-off-by: Joey Vagedes Cc: Rebecca Cran Cc: Liming Gao Cc: Bob Feng Cc: Yuwei Chen Reviewed-by: Yuwei Chen Reviewed-by: Liming Gao

BaseTools: Resolve regex syntax warnings

2023-12-21T00:33:31+00:00

Switches regex patterns to raw text to resolve python 3.12 syntax warnings in regards to invalid escape sequences, as is suggested by the re (regex) module in python. Cc: Rebecca Cran Cc: Liming Gao Cc: Bob Feng Cc: Yuwei Chen Signed-off-by: Joey Vagedes Reviewed-by: Rebecca Cran

BaseTools: add '-p' for Linux 'cp' command.

2022-07-17T02:20:51+00:00

Currently BaseTools use 'cp' command for PcdValueInit and GenMake process, as the command can not keep the time info of the source file, which will cause incremental build issue in Linux system, thus the '-p' need be added to keep the source file's attributes in copy process. This patch fixes this issue. Cc: Bob Feng Cc: Liming Gao Signed-off-by: Yuwei Chen Reviewed-by: Bob Feng

BaseTools: Fix the GenMake bug for .cpp source file

2022-06-28T09:14:55+00:00

Build-rules.txt lists .cc and .cpp as supported file extensions. BaseTools commit 05217d210e introduce a regression issue that ignore the .cc and .cpp file type. This patch is to fix this bug. Signed-off-by: Bob Feng Cc: Liming Gao Cc: Yuwei Chen Reviewed-by: Yuwei Chen

BaseTools: Remove RVCT support

2022-05-13T14:58:54+00:00

RVCT is obsolete and no longer used. Remove support for it. Signed-off-by: Rebecca Cran Reviewed-by: Ard Biesheuvel