bac9c74080
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 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 <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>
Edk2 Basetools
This folder has traditionally held the source of Python based tools used by EDK2.
The official repo this source has moved to https://github.com/tianocore/edk2-basetools.
This folder will remain in the tree until the next stable release (expected 202102).
There is a new folder under Basetools BinPipWrappers that uses the pip module rather than this tree for Basetools.
By adding the scope pipbuild-win or pipbuild-unix (depending on your host system), the SDE will use the
BinPipWrappers instead of the regular BinWrappers.
Why Move It?
The discussion is on the mailing list. The RFC is here: https://edk2.groups.io/g/rfc/topic/74009714#270 The benefits allow for the Basetools project to be used separately from EDK2 itself as well as offering it in a globally accessible manner. This makes it much easier to build a module using Basetools. Separating the Basetools into their own repo allows for easier CI and contribution process. Additional pros, cons, and process can be found on the mailing list.
How Do I Install It?
By default, EDK2 is tied to and tested with a specific version of the Basetools through pip-requirements.txt.
You can simply run:
pip install -r pip-requirements.txt
This will install the required module, thought we strongly suggest setting up a virtual environment. Additionally, you can also install a local clone of the Basetools as well as a specific git commit.