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

Renormalized end-of-lines from master@27b044605cd5f6b33a3d231576003850b3fe305b

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

BaseTools/Fmmt.py: Python 3.12 support

2024-04-23T21:36:22+00:00

Ref to https://docs.python.org/3/whatsnew/3.12.html A backslash-character pair that is not a valid escape sequence now generates Cc: Rebecca Cran Cc: Liming Gao Cc: Bob Feng Cc: Yuwei Chen Signed-off-by: Gua Guo Reviewed-by: Liming Gao

BaseTools: Use Stronger Matching for NULL Linked Libraries

2024-04-15T19:04:08+00:00

To prevent the possibility that a library with a name like NULLTestLib is interpreted as a NULL linked library, use more explicit pattern matching to ensure that the library name follows the pattern NULL%d. Cc: Rebecca Cran Cc: Liming Gao Cc: Bob Feng Cc: Yuwei Chen Signed-off-by: Taylor Beebe Reviewed-by: Liming Gao

BaseTools: Don't Recurse NULL Includes Not Linked to Module

2024-04-15T19:04:08+00:00

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 Cc: Liming Gao Cc: Bob Feng Cc: Yuwei Chen Signed-off-by: Taylor Beebe Reviewed-by: Liming Gao

BaseTools/GenFds: Apply OEM_CAPSULE_FLAGS during Capsule generation.

2024-03-13T10:53:30+00:00

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 Cc: Bob Feng Cc: Liming Gao Cc: Yuwei Chen Cc: Abner Chang Cc: Eric Xing Cc: Abdul Lateef Attar Reviewed-by: Liming Gao

BaseTools/GenFds: Resolve absolute workspace INF paths

2024-03-04T16:23:58+00:00

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 Cc: Liming Gao Cc: Bob Feng Cc: Yuwei Chen Signed-off-by: Michael Kubacki Reviewed-by: Rebecca Cran

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: Syntax warning invalid escape sequence \C

2024-02-28T00:23:58+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4666 This commit fixes the issue reported through BZ4666. The Syntax warning related to invalid escape sequence for \C is seen on Windows OS based builds of edk2 sources. On Windows the path seperator needs to prefixed with \ so essentially we need to use \\ as path seperator. Cc: Rebecca Cran Cc: Michael D Kinney Cc: Laszlo Ersek Cc: Liming Gao Cc: Bob Feng Cc: Yuwei Chen Cc: Jayaprakash N Signed-off-by: Jayaprakash N Reviewed-by: Laszlo Ersek Reviewed-by: Rebecca Cran

BaseTools: Update keybaord map based on UEFI spec 2.10

2024-02-26T15:32:09+00:00

REF: UEFI SPEC 2.10 34.8.10 EFI_KEY Add EfiKeyIntl0-9. Signed-off-by: Yi Li Cc: Rebecca Cran Cc: Liming Gao Cc: Bob Feng Cc: Yuwei Chen 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