summaryrefslogtreecommitdiffstats
path: root/BaseTools/Source
Commit message (Collapse)AuthorAgeFilesLines
* BaseTools: Fix multiple 'invalid escape sequence' warnings in testsMike Beaton2024-09-2318-72/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Python 3.12 invalid escape sequences in strings moved from DeprecationWarning to SyntaxWarning (ref https://docs.python.org/3/whatsnew/changelog.html#python-3-12-0-final and search for gh-98401). In a future Python version this will become SyntaxError. Multiple instances of these SyntaxWarnings are currently printed when running the BaseTools tests using Python 3.12 (though without actually failing the affected tests). This commit updates all lines which were causing this type of warning. Typical examples which needed fixing are: - "BaseTools\Source\Python" representing a path: "\S" and "\P" are invalid escape sequences, therefore left unchanged, therefore the test works (with a warning in Python 3.12). r"BaseTools\Source\Python" represents the same string, but with escapes turned off completely thus no warning. - Where '\t\s' is used as a regex pattern, then chr(9) + '\\s' is sent to the regex parser (with a warning in Python 3.12) since '\s' is not a valid Python escape sequence. This works correctly, though arguably for the wrong reasons. r'\t\s' sends the same as '\\t\\s', as originally intended and with no warning. (Note that ' and " are not fundamentally different in Python.) Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
* BaseTools: Update RETURN_ERROR Macro in BaseTypes.hAbdul Lateef Attar2024-09-201-1/+3
| | | | | | | | | | | | | | | | | | | | | | This patch is to sync RETURN_ERROR macro with the MdePkg/Include/Base.h Ref: 1a89d9887f MdePkg:Update Return Error Macro in Base.h Fixing RETURN_ERROR macro. It is causing problem in Coverity Static analysis tool as we are directly converting the UINT value to INTN. Changing value from UINT to INTN might cause problema Here we know that the values would not be in loss of data. To increase the code quality and increase the static tool analysis score we have to change it 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: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
* BaseTools: Update Stack Cookie LogicTaylor Beebe2024-09-133-1/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch updates the GenC logic to generate a random stack cookie value for the stack check libraries. These random values improve security for modules which cannot update the global intrinsics. If the stack cookie value is randomized in the AutoGen.h file each build, the build system will determine the module/library must be rebuilt causing effectively a clean build every time. This also makes binary reproducibility impossible. This patch updates the early build scripts to create 32 and 64-bit JSON files in the build output directory which each contain 100 randomized stack cookie values for each bitwidth. If the JSON files are already present, then they are not recreated which allows them to be stored and moved to other builds for binary reproducibility. Because they are in the build directory, a clean build will cause the values to be regenerated. The logic which creates AutoGen.h will read these JSON files and use a hash of the module GUID (the hash seed is fixed in Basetools) to index into the array of stack cookie values for the module bitwidth. This model is necessary because there isn't thread-consistent data so we cannot use a locking mechanism to ensure only one thread is writing to the stack cookie files at a time. With this model, the build threads only need to read from the files. Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* BaseTools: Remove Pip BaseToolsOliver Smith-Denny2024-09-101-29/+0
| | | | | | | | | | | | | | | | | | | | | | | | BaseTools was moved out to a separate repo and consumed as a pip module by edk2 CI. This process has not led to the desired goals of doing so, so this patch removes the pip based BaseTools from edk2 CI. The original goal of moving BaseTools to a pip module was primarily to speed up the development process, as the old edk2 mailing list was slow. However, with edk2 moving to PRs, it now actually slows the BaseTools development process to have to do a PR in another repo, publish the module, and then make a PR in edk2 to consume the new BaseTools. It also holds up using the features in a new BaseTools in other PRs. There were other goals of moving, such as allowing projects to use the BaseTools outside of edk2. This can still be accomplished outside of this PR, this PR simply stops edk2 CI from using the pip module. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* BaseTools: GenMake: FIx missing logs from GenMake.pyKen Lautner2024-09-021-0/+1
| | | | | | | EdkLogger logs were not showing up as part of the build log output. Adding the EdkLogger import to GenMake.py fixes the missing log prints. Signed-off-by: Kenneth Lautner <kenlautner3@gmail.com>
* BaseTools: Trim: Add header/footer for ASL includeJoey Vagedes2024-08-311-5/+28
| | | | | | | When including one ASL file in another, add a header / footer to the included file to easily tell where the included file starts and ends. Signed-off-by: Joey Vagedes <joey.vagedes@gmail.com>
* BaseTools/Capsule: Support Different Hash Algorithm for Payload DigestJason1 Lin2024-08-051-14/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4821 - The capsule payload digest got hardcoded inside the GenerateCapsule script as "sha256". - It would be hard for the caller to change the supported hash algorithm which supported on OpenSSL or Windows signtool program and platform. - Capsule payload digest signed data is followed by the PKCS#7 standard, in EDK-II CryptoPkg "Pkcs7Verify ()" is supported to validate with several hash algorithms naturally. (md5, sha1, sha256, sha384, and sha512) - Deliver below changes within this patch, (1) Introduce an optional argument "--hash-algorithm" to assign the caller expected one and leave the default value "sha256" to support the backward compatibility. (2) Add the double quotes to put the string of certificate's subject name inside it. (3) Set "Open" argument of "SignToolSubjectName" into "False". (4) Set "Convert" argument of "SignToolSubjectName: into "str". (5) Correct the actual name of the "--subject-name" flag. (6) Add back correct number of arguments for PayloadDescriptor class object initializing. Note: - Platform needs to support the correspond hash algorithm to validate the digital signature or the failure would be observed. - Set the md5 and sha1 algorithm as EOL based on the CryptoPkg supported table and reject the capsule creation. Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
* BaseTools: Move MEMORY_TYPE_* Defines to EFI_MEMORY_TYPE EnumDmitry Antipov2024-07-261-1/+14
| | | | | | | | | | | | Per TCBZ2372, clang on Linux emits a warning if an enum-typed variable is compared with a constant outside of the range of the enum. Such comparisons are performed in multiple locations in DXE core on variables of type EFI_MEMORY_TYPE. This patch moves the OEM and OS reserved types into the EFI_MEMORY_TYPE enum itself to resolve this issue and improve readability. This commit does this for the BaseTools copy of this enum. Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* BaseTools: drop GeneralCheckNonAscii() from ECCLeif Lindholm2024-07-154-27/+0
| | | | | | | | | | | | | | | The GeneralCheckNonAscii() function is a sledgehammer rejecting any file containing any character outside of the 7-bit ASCII encoding space, as well as the DEL character (which seems unrelated). This conflicts with basic stuff like correctly spelling certain proper nouns in comments (like copyright statements), or string literals (for example in multi-language driver binding ComponentNames). So rip it out, to be replaced by more fine-grained checks to be added as identified and needed. Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
* BaseTools: fix consistent Ecc misspelling of ASCIILeif Lindholm2024-07-154-13/+13
| | | | | | | | Ecc concistently referred to ASCII/Ascii as ACSII/Acsii, which bugged me to no end when trying to figure out how those tests worked. Fix all instances. Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
* 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: Update keybaord map based on UEFI spec 2.10Yi Li2024-02-261-1/+11
| | | | | | | | | | | | | | REF: UEFI SPEC 2.10 34.8.10 EFI_KEY Add EfiKeyIntl0-9. Signed-off-by: Yi Li <yi1.li@intel.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: Liming Gao <gaoliming@byosoft.com.cn>
* 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/GenFw: Correct offset when relocating an ADRJake Garver2023-12-211-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When converting ELF to PE/COFF for the AArch64 target, we may encounter an R_AARCH64_ADR_GOT_PAGE relocation that refers to an ADR instruction instead of an ADRP instruction. This can happen when the toolchain is working around Cortex-A53 erratum #843419. If that's the case, be sure to calculate the offset appropriately. This resolves an issue experienced when building a StandaloneMm image (which is built with -fpie) with stack protection enabled on GCC compiled with "--enable-fix-cortex-a53-843419". In this case, the linker may convert an ADRP instruction appearing at an offset of 0xff8 or 0xffc modulo 4KiB into an ADR instruction, but will leave the original R_AARCH64_ADR_GOT_PAGE relocation in place. (This is not a bug in the linker, given that there is no other relocation type that it could reasonably convert it into) In this scenario, the following code is being generated by the toolchain: # Load to set the stack canary 2ffc: 10028020 adr x0, 8000 <mErrorString+0x1bc> 3008: f940d400 ldr x0, [x0, #424] # Load to check the stack canary 30cc: b0000020 adrp x0, 8000 <mErrorString+0x1bc> 30d0: f940d400 ldr x0, [x0, #424] GenFw rewrote that to: # Load to set the stack canary 2ffc: 10000480 adr x0, 0x308c 3008: 912ec000 add x0, x0, #0xbb0 # Load to check the stack canary 30cc: f0000460 adrp x0, 0x92000 30d0: 912ec000 add x0, x0, #0xbb0 Note that we're now setting the stack canary from the wrong address, resulting in an erroneous stack fault. After this fix, the offset will be calculated correctly for an ADR and the stack canary is set correctly. Note that there is a corner case where this may cause the conversion to fail: if the original GOT entry is just within -/+ 1 MiB of the reference, but the actual variable it refers to is not, the resulting offset cannot be represented by the immediate offset field in a ADR instruction. Given that this issue only affects PIE executables, which are rare and usually tiny, this is unlikely to cause problems in practice. Ref: https://edk2.groups.io/g/devel/topic/102202314 [ardb: expand commit log, add reference] Signed-off-by: Jake Garver <jake@nvidia.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* 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: GenFw: auto-set nxcompat flagJoey Vagedes2023-11-061-0/+69
| | | | | | | | | | | | | | | | | | | | Automatically set the nxcompat flag in the DLL Characteristics field of the Optional Header of the PE32+ image. For this flag to be set automatically, the section alignment must be evenly divisible by 4K (EFI_PAGE_SIZE) and no section must be executable and writable. Adds a command line flag to GenFw, --nonxcompat, to ensure the IMAGE_DLLCHARACTERISTICS_NX_COMPAT bit is not set, even if all requirements are met. Updates the manual for GenFw to include the new flag. 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 <joeyvagedes@gmail.com> Acked-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Rebecca Cran <rebecca@bsdio.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/GenFw: Add support for LOONGARCH64 relax relocationDongyan Qian2023-09-252-1/+32
| | | | | | | | | | | | | | | | Correct relax id from 99 to 100 and added relocation support up to 109 fix gcc14 adds new relocation, and the generated relocation causes the build and compilation to fail. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4559 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> Cc: Chao Li <lichao@loongson.cn> Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn> Reviewed-by: Chao Li <lichao@loongson.cn>
* BaseTools: Remove logic to create AP waking vector in GenFvZhiguang Liu2023-09-181-199/+0
| | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4494 Today for SEC core(not VTF-0), GenFv finds free 4K aligned space in FV for AP waking vector and JMP to 4G-30h in the waking vector. There is no usage of this today. Remove the logic to avoid confusing and save spaces in reset vector. 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: Ray Ni <ray.ni@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* BaseTools: remove duplicate includes: IndustryStandard/*.hGerd Hoffmann2023-06-017-740/+2
| | | | | | | | Use the MdePkg versions instead of maintaining a copy in BaseTools. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools: remove duplicate includes: IndustryStandard/PeImage.hGerd Hoffmann2023-06-011-790/+0
| | | | | | | | | Use the MdePkg version instead of maintaining a copy in BaseTools. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Chao Li <lichao@loongson.cn> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools: switch from EFI_IMAGE_MACHINE_* to IMAGE_FILE_MACHINE_*Gerd Hoffmann2023-06-017-55/+50
| | | | | | | | | Use the newer versions of the machine #defines. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Chao Li <lichao@loongson.cn> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools: drop IMAGE_FILE_MACHINE_ARM hacksGerd Hoffmann2023-06-011-19/+4
| | | | | | | | | The #define for IMAGE_FILE_MACHINE_ARM is not present in MdePkg, this looks like a relic not used any more. Remove. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools: remove duplicate includes: IndustryStandard/Acpi*.hGerd Hoffmann2023-06-018-1595/+7
| | | | | | | | | Use the MdePkg version instead of maintaining a copy in BaseTools. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools: remove duplicate includes: <arch>/ProcessorBind.hGerd Hoffmann2023-06-019-806/+19
| | | | | | | | | Use the MdePkg version instead of maintaining a copy in BaseTools. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Chao Li <lichao@loongson.cn> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools: remove WinNtInclude.hGerd Hoffmann2023-06-016-75/+0
| | | | | | | | | Appears to be a relic for ancient windows / compiler versions, windows builds in CI work just fine without it. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-19 14:24:22 +0000