summaryrefslogtreecommitdiffstats
path: root/BaseTools/Source/Python
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* BaseTools: Remove RVCT supportedk2-stable202205-rc1Rebecca Cran2022-05-134-16/+6
| | | | | | | | RVCT is obsolete and no longer used. Remove support for it. Signed-off-by: Rebecca Cran <quic_rcran@quicinc.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* BaseTools: Add FMMT Python ToolChen, Christine2022-05-0620-0/+2695
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FMMT python tool is used for firmware files operation, which has the Fv/FFs-based 'View'&'Add'&'Delete'&'Replace' operation function: 1.Parse a FD(Firmware Device) / FV(Firmware Volume) / FFS(Firmware Files) 2.Add a new FFS into a FV file (both included in a FD file or not) 3.Replace an FFS in a FV file with a new FFS file 4.Delete an FFS in a FV file (both included in a FD file or not) 5.Extract the FFS from a FV file (both included in a FD file or not) This version of FMMT Python tool does not support PEIM rebase feature, this feature will be added in future update. Currently the FMMT C tool is saved in edk2-staging repo, but its quality and coding style can't meet the Edk2 quality, which is hard to maintain (Hard/Duplicate Code; Regression bugs; Restrict usage). The new Python version keeps same functions with origin C version. It has higher quality and better coding style, and it is much easier to extend new functions and to maintain. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1847 RFC Link: https://edk2.groups.io/g/devel/message/82877 Staging Link: https://github.com/tianocore/edk2-staging/tree/PyFMMT 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> Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
* BaseTools: Move gPlatformFinalPcd to Datapipe and optimize sizeLi, Yi12022-04-225-11/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3828 This is a bugfix of bf9230a9f3dde065c3c8b4175ccd32e44e8f0362. 1.In the current code, gPlatformFinalPcd will save all PCDs used at whole compile process, which wastes runtime memory and is unnecessary. This patch makes gPlatformFinalPcd save only the PCDes which are assigned in the DSC file, and the PCD that has not been assigned will use the default value in DEC. 2.During the compilation process, gPlatformFinalPcd may be lost, and the current code cannot selectively assign PCD in DSC by specifying ARCH. This patch moves gPlatformFinalPcd into datapipe and modifies the assignment logicto fix this. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: yi1 li <yi1.li@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools:Support decimal version number in ECC checkwenyi,xie via groups.io2022-03-281-3/+15
| | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3872 When doing ecc inf version check, the decimal type version number like 1.27 is treated as invalid version. So the code should be updated to support decimal type version number. 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: Wenyi Xie <xiewenyi2@huawei.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: Remove the redundant __FLEXIBLE_SIZE from PcdValueInit.cBob Feng2022-03-261-0/+5
| | | | | | | | | | | | | | | For the multiple SKU case, basetools generates multiple redundant __FLEXIBLE_SIZE statement that is from the same line in dsc file. This behavior causes the generated PcdValueInit.c file to have huge size, and the compilation time is very long. This patch is going to fix this issue. 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: Add the FeatureFlagExpression usage to the Source SectionYi Li2022-03-265-5/+59
| | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3828 FeatureFlagExpression Support in Source section of INF file. The Pcd value in the expression is from INF or DEC. When a FeatureFlagExpression is present,if the expression evaluates to TRUE,then the entry is valid. If the expression evaluates to FALSE, then the EDK II build tools must ignore the entry. This patch is going to add this feature. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Heng Luo <heng.luo@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Yi Li <yi1.li@intel.com>
* BaseTools: Fix error leg in DscBuildData.pyJake Garver via groups.io2022-02-071-1/+1
| | | | | | | | | | | Fix a Edk2Logger.warn() message format to match the arguments. We ran into this after a failure in PcdValueInit. The failure was masked by a new exception, "TypeError: not all arguments converted during string formatting". Signed-off-by: Jake Garver <jake@nvidia.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* BaseTools: Fix wrong variable header sizeChen, Lin Z2022-01-131-1/+5
| | | | | | | | | There are two type variable header and their size are different, need to use matched size when calculating offset info, otherwise it'll destroy other variables content when patching. Signed-off-by: Chen, Lin Z <lin.z.chen@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* BaseTools: Fix the bug of --cmd-len build optionBob Feng2021-12-282-0/+3
| | | | | | | | | | currently the --cmd-len build option does not work. This patch is going 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>