summaryrefslogtreecommitdiffstats
path: root/BaseTools/Source/Python
Commit message (Collapse)AuthorAgeFilesLines
* BaseTools/Ecc: Allow `static` as a modifierMichael Kubacki2024-07-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, `STATIC` is allowed as a function modifier but `static` results in the below ECC errors: ``` *Error code: 5001 *Return type of a function should exist and in the first line *file: D:\src\edk2\Build\.pytool\Plugin\EccCheck\MdePkg\Library\UefiDebugLibDebugPortProtocol\DebugLibConstructor.c *Line number: 37 *[UefiDebugLibDebugPortProtocolExitBootServicesCallback] Return Type should appear at the start of line EFI coding style error *Error code: 5002 *Any optional functional modifiers should exist and next to the return type *file: D:\src\edk2\Build\.pytool\Plugin\EccCheck\MdePkg\Library\UefiDebugLibDebugPortProtocol\DebugLibConstructor.c *Line number: 37 ``` This is because `GetDataTypeFromModifier()` will return both `static` and the return type (e.g. `VOID`) whereas for a modifier in the list (e.g. `STATIC`) it will return only the return type allowing logic in Ecc/c.py to process the modifier and return type with current logic. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
* BaseTools/GenerateCapsule.py: Fix checking for DepExp presenceSergii Dmytruk2024-07-051-2/+2
| | | | | | | | | | | struct.unpack() returns a tuple even for a single-element pack, resulting in signature verification being evaluated to false even when the signature is there. This fixes --decode and --dump-info actions incorrectly reporting issues with parsing capsule dependencies when there are none. Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
* BaseTools/GenerateCapsule.py: Fix inconsistent error formattingSergii Dmytruk2024-07-051-2/+2
| | | | | | | Just add a space between colon and a more detailed error message in two places. Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
* BaseTools/GenerateCapsule.py: Require --output for --decodeSergii Dmytruk2024-07-051-0/+4
| | | | | | | | | | | --decode unconditionally uses args.OutputFile.name as a prefix for output files that it creates and fails in a non-pretty way without --output option. This doesn't address creation/truncation of the file specified via --output, but at least you're able to decode a capsule. Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
* BaseTools/GenerateCapsule.py: Better error message on --decode failureSergii Dmytruk2024-07-051-2/+2
| | | | | | Print error text from the exception. Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
* BaseTools/GenerateCapsule.py: Disallow UpdateImageIndex == 0 on --encodeSergii Dmytruk2024-07-051-3/+3
| | | | | | | | | This field seems to be one-based according UEFI specification, default value is 1 and --decode of GenerateCapsule.py errors upon seeing UpdateImageIndex less than 1. So align --encode behaviour to enforce a value within the 1..255 range. Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
* BaseTools/GenerateCapsule.py: Fix --decode operationSergii Dmytruk2024-07-051-1/+1
| | | | | | | | | | | Commit b68d566439683d0ebe60d52c85ff0e90331db740 added support for input subject name with signtool and broke --decode operation by using incorrect identifier in one place (could be an incomplete rename during review). It's `args.SignToolSubjectName`, not `args.SignSubjectName`. Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
* BaseTools/FmpCapsuleHeader.py: Explain error when throwing exceptionsSergii Dmytruk2024-07-051-11/+11
| | | | | | This gives a caller a chance to report a meaningful error to the user. Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
* BaseTools: InfBuildData: Fix Private value retrievalJoey Vagedes2024-07-041-7/+7
| | | | | | | | | | | | | | | | | Update retrieval of private guids, protocols, or ppis from a package's declaration file to use the original path of the module's INF file rather than the current path. When building the same module multiple times in the same INF (by override the define's FILE_GUID), a temporary instance of the module is generated outside the package, causing the retrieval of private values to fail as the check to access private values is done by verifying the module to build, is inside the package. Signed-off-by: Joey Vagedes <Joey.Vagedes@gmail.com> 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>
* BaseTools/BuildReport: Improve compile_commands generationJeff Brasen2024-06-151-6/+13
| | | | | | | | | | | | | 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>
* BaseTools/Fmmt.py: Python 3.12 supportGua Guo2024-04-231-1/+1
| | | | | | | | | | | | | 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 <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: Gua Guo <gua.guo@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* BaseTools: Use Stronger Matching for NULL Linked LibrariesTaylor Beebe2024-04-152-6/+6
| | | | | | | | | | | | | | | 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 <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>
* BaseTools: Don't Recurse NULL Includes Not Linked to ModuleTaylor Beebe2024-04-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* BaseTools/GenFds: Apply OEM_CAPSULE_FLAGS during Capsule generation.Igniculus Fu2024-03-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* BaseTools/GenFds: Resolve absolute workspace INF pathsMichael Kubacki2024-03-041-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* BaseTools/AutoGen: declare ProcessLibraryConstructorList() for SEC modulesLaszlo Ersek2024-02-291-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* BaseTools: Syntax warning invalid escape sequence \CJayaprakash, N2024-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | | 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 <rebecca@bsdio.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Jayaprakash N <n.jayaprakash@intel.com> Signed-off-by: Jayaprakash N <n.jayaprakash@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools: Remove Duplicate sets of SkuName and SkuId from allskusetAshraf Ali S2024-02-081-0/+2
| | | | | | | | | | | | | | | | | | | 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 <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> Signed-off-by: Ashraf Ali S <ashraf.ali.s@intel.com> Reviewed-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Amy Chan <amy.chan@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: Optimize GenerateByteArrayValue and CollectPlatformGuids APIsdevel@edk2.groups.io2024-02-082-58/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Basetools: Include PCD declarations from Library Instancelevi.yun2024-01-311-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* BaseTools: Fix raw strings containing valid escape charactersJoey Vagedes2024-01-103-4/+4
| | | | | | | | | | | | | | | 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 <joey.vagedes@gmail.com> 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> Reviewed-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* BaseTools: Resolve regex syntax warningsJoey Vagedes via groups.io2023-12-2118-60/+60
| | | | | | | | | | | | | 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 <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: Joey Vagedes <joey.vagedes@gmail.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools: FMMT GuidTool Auto Select Config file EnablingRebecca Cran2023-12-201-1/+1
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4624 Currently, Python FMMT tool does not support automatically select FMMTConf.ini file which saves GuidTool settings. This patch supports this features. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools: fixing FMMT ShrinkFv issueYuwei Chen2023-12-112-4/+8
| | | | | | | | | | | | 1. FvLength not change issue; 2. FileSystemGuid align with File Size; Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: FMMT support ELF UPLD parserYuwei Chen2023-12-116-5/+383
| | | | | | | | | | | | | | | | | | | | | | | | | FMMT add new function to support the .elf file parsing. Using '-v' option, the UPLD info will be printed out. ''' - UNIVERSAL_PAYLOAD_INFO - 4 bytes align (BOOLEAN) - Identifier - SpecRevision - Attribute - Revision - Capability - ProducerId - ImageId UPLD Buffer ''' Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: FMMT replace output file is not generated successfullyYuwei Chen2023-12-112-5/+18
| | | | | | | | | | | | | For replace function, when target Ffs and new ffs are with same size, the output file can not be generated successfully. This patch fixes this issue. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: FMMT replace new free space fixing in replaceYuwei Chen2023-12-111-1/+1
| | | | | | | | | | | | | | In FMMT replace function, when newffs size <= targetffs size, the new free space is calculated wrong as loss the pad data delta size. That will cause invalid binary generated. This patch fixes this issue. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: trim warning to errorYuwei Chen2023-10-181-2/+2
| | | | | | | | | | | | As the error is changed to warning, Trim.py will skip the build error when the source code have exactly issue. This patch change warning to error to opens the checking. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools: Allow users to specify compiler to use with make CC= CXX=Rebecca Cran2023-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | 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>
* BaseTools: Extend fields for module_report.jsonGuillermo Antonio Palomino Sosa2023-03-111-0/+4
| | | | | | | | | | | Adding following fields to module_report.json: * LibraryClass * ModuleEntryPointList * ConstructorList * DestructorList Signed-off-by: Guillermo Antonio Palomino Sosa <guillermo.a.palomino.sosa@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: Generate compile information in build reportPalomino Sosa, Guillermo A2023-03-112-3/+140
| | | | | | | | | | | | | | | | | | | | | 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>
* BaseTools: Add missing spaces for PCD expression values in AutoGenCKonstantin Aladyshev2022-10-191-1/+1
| | | | | | | | | | | | | | | | | | | | | 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>
* BaseTools: Correct initialization data size check for array PCDsKonstantin Aladyshev2022-10-191-8/+8
| | | | | | | | | | | | | | | 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>
* BaseTools/GenFds: Correct file type set for the PIC sectionKonstantin Aladyshev2022-10-191-1/+1
| | | | | | | | | | 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>
* BaseTools: Support COMPAT16 section generationKonstantin Aladyshev2022-10-191-0/+1
| | | | | | | | | | | | | | | | | Currently COMPAT16 section type is not recognized and GenSec is called without the "-s [SectionType]" argument. Add COMPAT16 type to the SectionType dictionary to fix the issue. Now this syntax works correctly: ``` FILE FREEFORM = <GUID> { SECTION COMPAT16 = <FILE> } ``` 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>
* BaseTools: Add support for SUBTYPE_GUID section generationKonstantin Aladyshev2022-10-193-0/+110
| | | | | | | | | | | | | | | EFI_SECTION_FREEFORM_SUBTYPE_GUID is a leaf section type that contains a single EFI_GUID in the header to describe the raw data. Currently is is not possible to generate such section. This patch adds initial support for the generation of such sections. The added syntax for this type of section corresponds to EDKII "[FV] section" documentation from the FDF Specification: ``` SECTION SUBTYPE_GUID <GUID> = <File> ``` Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: Correct BPDG tool error printsKonstantin Aladyshev2022-10-191-2/+2
| | | | | | | | | | Popen communication returns bytestrings. It is necessary to perform decode on these strings before passing them to the EdkLogger that works with ordinary strings. 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>
* BaseTools/FMMT: Add Shrink Fv functionChen, Christine2022-10-193-1/+60
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3938 This function is used to remove the useless FV free space. Usage: FMMT -s Inputfile Outputfile Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools/FMMT: Add Extract FV functionChen, Christine2022-10-193-22/+31
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3938 With this patch "-e" parameter supports extract FV function. Usage: FMMT -e Inputfile TargetFv Outputfile Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: Remove duplicated words in Python toolsPierre Gondois2022-10-192-2/+2
| | | | | | | | | | In an effort to clean the documentation of the above package, remove duplicated words. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
* BaseTools: Updated build tools to support new LoongArch.Chao Li2022-10-143-4/+44
| | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4053 Python code changes for building EDK2 LoongArch platform. 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: Chao Li <lichao@loongson.cn> Co-authored-by: Baoqi Zhang <zhangbaoqi@loongson.cn> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* Revert "BaseTools: Fix DSC LibraryClass precedence rule"Liming Gao2022-08-281-2/+2
| | | | | | | | | This reverts commit 039bdb4d3e96f9c9264abf135b8a0eef2e2b4860 for tag202208. This brings the behavior changes, and needs more discussion. Signed-off-by: Liming Gao <gaoliming@byosoft.com.cn> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools/Capsule: Support signtool input subject name to sign capsule fileJason1 Lin2022-07-271-9/+34
| | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3928 Windows-based system using signtool.exe to sign the capsule. Add the support to using "--subject-name" argument to assign the subject name used to sign the capsule file. This argument would pass to signtool.exe as a part of input argument with "/n" flag. NOTE: If using signtool.exe to sign capsule at least need to choose one of "--pfx-file" and "--subject-name" argument to input the value. Signed-off-by: Jason1 Lin <jason1.lin@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Dakota Chiang <dakota.chiang@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: INF should use latest Pcd value instead of default valueLi, Yi12022-07-241-1/+3
| | | | | | | | | | | | | | This patch is a bug fix about FeatureFlagExpression in INF file: INF [Source] section now unconditionally use Pcd default value in DEC when handling FeatureFlagExpression, it is wrong. If a Pcd value has been set in the DSC file, we should use latest value in DSC instead of default value. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Yi Li <yi1.li@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: Fix DSC LibraryClass precedence ruleChen, Christine2022-07-171-2/+2
| | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3965 Currently DSC LibraryClass precedence rule is not align with DSC Spec. The expectation rule should be: [LibraryClasses.$(ARCH)] < [LibraryClasses.Common.$(MODULE_TYPE)] The actual behavior is: [LibraryClasses.$(ARCH)] > [LibraryClasses.Common.$(MODULE_TYPE)] This patch fixes the issue. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Long1 Huang <long1.huang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: add '-p' for Linux 'cp' command.Chen, Christine2022-07-172-3/+3
| | | | | | | | | | | | | | | 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 <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: Fix the GenMake bug for .cpp source fileFeng, Bob C2022-06-281-1/+2
| | | | | | | | | | | | | 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 <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Yuwei Chen<yuwei.chen@intel.com>
* BaseTools/Ecc: Fix grammar in Ecc error messageRebecca Cran2022-06-271-2/+2
| | | | | | Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com> Reviewed-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: output the intermediate library instance when error occursNi, Ray2022-06-161-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a module "Module" depends on a library instance "Lib1" which depends on "Lib2" which depends on "Lib3" ... depends on "LibN", but "LibN" doesn't support the type (e.g.: SEC) of the "Module", the following error messages are printed by build tool: <DSC path>(...): error 1001: Module by library instance [<LibN path>] consumed by [<Module path>] But it's unclear to user how LibN is consumed by the Module. With the patch, following errors are printed: <DSC path>(...): error 1001: Module by library instance [<LibN path>] consumed by library instance [<Lib N-1 path>] which is consumed by module[<Module path>] It doesn't print all the intermediate library instances between the Module and LibN but at least the path of Lib N-1 can help users to help how to fix the build errors. I hope this patch can be a trigger point that a better solution could be developed by tool experts to print all the library instances between the Module and LibN. Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Bob Feng <bob.c.fen@intel.com>
* BaseTools: Fix dependency issue in PcdValueInitJake Garver2022-06-061-1/+2
| | | | | | | | | The generated Makefile was missing a dependency. This resulted in a build-time race condition if the recursive make is multi-threaded and shares job control. Signed-off-by: Jake Garver <jake@nvidia.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-03-07 06:09:52 +0000