summaryrefslogtreecommitdiffstats
path: root/BaseTools
Commit message (Collapse)AuthorAgeFilesLines
* BaseTools/tools_def: Use no-warn-rwx-segments only for GCC5Ard Biesheuvel2025-02-011-3/+3
| | | | | | | | | | | | | The command line option --no-warn-rwx-segments was added to the linker command line for all GCC family builds on ARM and AARCH64, including CLANGDWARF and GCC49 and older, none of which are intended for use with linkers that actually understand this option. So instead, move it to the GCC5 DLINK FLAGS definitions for ARM and AARCH64 (which are inherited by the versionless GCC which is intended to replace GCC5 at some point). Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* BaseTools/Pccts: set C standardGerd Hoffmann2025-01-312-2/+2
| | | | | | | | The prehistoric code base doesn't build with ISO C23. Set the C standard to C11 (for both clang and gcc) so it continues to build with gcc 15 (which uses C23 by default). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* BaseTools: Fix NoneType parent reference in FMMT operationsAshraf Ali S2025-01-271-3/+12
| | | | | | | | | | | | | | | | | | This patch addresses an issue in the FMMT operations where the parent reference is not checked for NoneType. This oversight can lead to an AttributeError: 'NoneType' object has no attribute 'Name' when attempting to access the parent reference. The fix involves adding a check for NoneType before accessing the parent reference to ensure that the operations handle such cases gracefully. The affected functions include: - AddNewFfs - ReplaceFfs - ExtractFfs These functions now include proper checks to prevent the AttributeError. Signed-off-by: Ashraf Ali S <ashraf.ali.s@intel.com>
* BaseTools: Break Build on Linker WarningsOliver Smith-Denny2025-01-221-14/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | Today VS2022 and GCC are set to treat all compiler warnings as errors and break the build. However, linker warnings for both do not break the build. There are critical errors that can be treated as warnings as the linker, such as not finding the module entry point and use a default address as the entry point. This will cause a runtime crash for something that should be caught at build time. This commit adds /WX to VS2022's DLINK_FLAGS and --fatal-warnings to GCC's DLINK_FLAGS for IA32, X64, ARM, and AARCH64 in order to break the build on linker warnings. VS2022 linker warning 4210 is ignored for all builds because it checks for static initializers and the linking of the VCRuntime. edk2 never links the VCRuntime (except for HOST_APPLICATIONs) and so the presence of static initializers will always cause this warning, even when the edk2 code calls these initializers that would otherwise be called in the _CRT_INIT function of the VCRuntime. At the time of this commit, it only fails in CryptoPkg for building OpenSSL, but could fail anywhere a static initializer is used. Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
* BaseTools/Plugin/HostBasedUnitTestRunner: Set ASAN env varsMichael D Kinney2025-01-211-0/+6
| | | | | | | | | | | | | | | | | | The environment variable `GTEST_CATCH_EXCEPTION` must be set to `0` for so all exceptions are handled by the address sanitizer and not GoogleTest. This allows stack back trace and other details to be logged by the address sanitizer so the source of the issue identified address sanitizer can be determined. The environment variable `ASAN_OPTIONS` must be set to `detect_leaks=0` to disable memory leak detection. The unit test frameworks may have memory leaks and some firmware code under test use cases may perform a memory allocation without a matching memory free as their expected behavior. Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools/Conf: Simplify VS20xx HOST_APPLICATION buildsMichael D Kinney2025-01-212-1/+32
| | | | | | | | | | | | | | | | | | Add Empty_C_File_Host_Application_Build.c to BaseTools/Conf that is a C source file with only comments that is used to compile into an OBJ file using CC_FLAGS for a HOST_APPLICATION module and the OBJ is passed into the VS20xx DLINK action to provide the context required to select the correct default windows application libraries. Update build_rule.template to compile the empty C file and generate OBJ in the OUTPUT_DIR of the HOST_APPLICATION component and use the OBJ in the DLINK action. This simplifies CC_FLAGS and DLINK_FLAGS for all modules of type HOST_APPLICATION. Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: build_rule.template generate a different dll for wholearchive.Aaron Pop2025-01-151-2/+4
| | | | | | | | | | When running the /wholearchive test build, generate the test .dll as a different filename to prevent the system holding onto the dll file too long and generating a build error that the actual dll cannot be found. Remove the temporary file after it was generated because the successful completion of the link command is the test case. Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
* BaseTools: Clean up os.path.normcase and os.path.normpath usageYang Gang2025-01-095-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | Refer to the docs of python, `os.path.normcase(path)` function: "Normalize the case of a pathname. On Windows, convert all characters in the pathname to lowercase, and also convert forward slashes to backward slashes. On other operating systems, return the path unchanged." `os.path.normpath(path)` also convert forward slashes to backward slashes. So call `os.path.normcase` after `os.path.normpath` just convert path to lowercase on Windows(only). And Windows is case-insensitive but case-preserving. So the usage of `os.path.normcase(os.path.normpath(path))` can be simplified to `os.path.normpath(path)`. Then we can use case-preserving paths rather than lowercase paths in compile_commands.json file or build log. But this patch continue to use `os.path.normcase` when comparing/searching paths. Signed-off-by: Yang Gang <yanggang@byosoft.com.cn>
* BaseTools: Skip directories with code extensions in the nameAlexander Gryanko2025-01-071-1/+1
| | | | | | | | | | | | | | | | | Currently openssl has an Open Quantum Safe provider submodule with directories like oqs-provider/oqs-template/oqsprov/oqsprov.c or oqs-provider/oqs-template/oqsprov/oqsprov/oqsprov_capabilities.c that are used as templates, but DebugMacroCheck tries to read them as a file when recursively traversing the subdirectories. Fail message: File "/usr/lib/python3.10/pathlib.py", line 1119, in open return self._accessor.open(self, mode, buffering, encoding, errors, IsADirectoryError: [Errno 21] Is a directory: '/CryptoPkg/Library /OpensslLib/openssl/oqs-provider/oqs-template/oqsprov/oqsprov.c' Signed-off-by: Alexander Gryanko <xpahos@gmail.com>
* Remove dependancy on re.TAshraf Ali2024-12-241-1/+0
| | | | Signed-off-by: Ashraf Ali <ashraf.ali.s@intel.com>
* BaseTools: Support custom library build for base tools on Linux ARMkuqin122024-12-207-8/+127
| | | | | | | | | | | | | | | | | | | This change added the build script to cross compile the base tool binaries for Linux ARM/AARCH64 systems. The needed libuuid system library is pulled from source file and rebuilt to support the corresponding library dependencies. Individual tools' makefiles are also updated to link the cross compiled library as well. The EDK2 base tool build script was also updated to support such change. This was tested functional on Linux ARM host system. 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: Kun Qin <kun.qin@microsoft.com>
* BaseTools: Adding cross compilation of BaseTool for Windows ARM/ARM64Kun Qin2024-12-205-14/+135
| | | | | | | | | | | | | | | | | | This change adds the support of crossbuilding basetool for Windows ARM/ ARM64 systems, which will enable the generally available pipeline agents to build binary tools and make releases as they see fit. The EDK2 base tools build script is also updated to support cross compilation using this script. The crossbuilt binary output is tested on Windows ARM based hardware systems. 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: Kun Qin <kun.qin@microsoft.com>
* BaseTools: Adding support of building BaseTool on Windows ARM/ARM64kuqin122024-12-207-0/+29
| | | | | | | | | | | | | | | | | | | This change focuses on the support of building basetool natively for Windows ARM/ARM64 host system, which will enable the ARM based platforms to build UEFI and unit tests. Note that the warnings due to integer conversions are suppressed for this specific target to avoid too much local changes carried in MU. The formal change should drop all these binaries and move to pythonic scripts. The binary output is tested on Windows ARM based hardware systems. 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: Kun Qin <kun.qin@microsoft.com>
* BaseTools: fix spelling errorWilliam Leara2024-12-111-1/+1
| | | | | | No functional change. Signed-off-by: William Leara <william.leara@dell.com>
* BaseTools: Typo fixesDionna Glaze2024-12-116-15/+13
| | | | | | Some in error messages, some in local variable names. Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
* BaseTools: Update alignment for entry seg for ClangDhaval2024-12-112-6/+11
| | | | | | | | | | | | | | | | It does 3 things: 1. Use separate linker file for clang vs GCC for RISCV64. 2. Use common page size instead of max page to ensure -z option align values are properly applied. 3. Enforce alignment for .entry segment as per -z option. When we want to have -z option aligned images, clang while alignes .text and .data segments correctly, .entry segment is by default not aligned unless explicitly specified. This patch makes it explicit to clang that entry seg should also be aligned to requirements. Somehow GCC does not require such explicit entry. Hence detachiong both ld files. Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com>
* Update CI to VS2022Oliver Smith-Denny2024-12-102-3/+3
| | | | | | | | | This PR updates the CI pipelines to use VS2022 instead of VS2019 as that is the latest supported VS toolchain on edk2. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
* BaseTools: Add VS2022 XIPFLAGSOliver Smith-Denny2024-12-103-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BaseTools has a limitation that modules in FVs that are force rebased must have the same file and section alignment. This is intended for XIP modules. VS2019 and previous VS toolchains did not set 4k section alignment, but VS2022 does, in order for memory protections to be applied to images. This causes issues when building SEC and PEI modules on VS2022 as the file alignment is 0x20 but the section alignment is 0x1000, so BaseTools will fail to generate the FV. One option is to set the file alignment to 0x1000 for all of these files, but that is a large waste of space and is not feasible on some platforms that have limited flash space. The other option is to selectively set 0x20 as the section alignment for SEC and PEI modules, which is the approach GCC ARM/AARCH64 took. This is only an issue for building 64-bit PEI on x86 currently, as other architectures are not supported by VS2022 in edk2 yet. For IA32, the section alignment is set to 0x20 and so it matches the file alignment, however x64 PEI uses the X64 DLINK flags which have 0x1000 set. For other architectures that don't have the PEI/DXE architecture split, this is also an issue. This commit is required to use VS2022 as the default CI in edk2, as OvmfPkgX64.dsc will fail to build. Any platform with 64-bit PEI also requires this. This commit also updates CryptoPkg.dsc and SecurityPkg.dsc as they are setting custom section alignments. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
* BaseTools: Add /WHOLEARCHIVE for VS2022 BuildsOliver Smith-Denny2024-12-101-1/+1
| | | | | | | | | | | | | VS2022's DLINK2_FLAGS (containing only /WHOLEARCHIVE) was commented out during upstreaming, due to some downstream platform issues when /WHOLEARCHIVE was set. This does not prove an issue for edk2 and is what is used for earlier versions of VS, so is added here for VS2022. If platforms see issues, bugs should be filed on edk2 (or fixed in the platform if applicable). Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
* BaseTools: Improve error messages from UefiCapsuleHeader.pyRebecca Cran2024-12-061-2/+2
| | | | | | | Instead of throwing ValueErrors with no explanation, add a message explaining what went wrong. Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools: Coverage: Detect lcov versionOliver Steffen2024-12-051-1/+20
| | | | | | | | | Detect the version of lcov and only apply version 2 workaround when needed. Fixes 61c714285f8c Signed-off-by: Oliver Steffen <osteffen@redhat.com>
* BaseTools: Coverage: make lcov v2.0 workOliver Steffen2024-12-041-1/+2
| | | | | | | | | | | | | lcov 2.0 and newer does additional error and consistency checking compared to previous versions. This can lead to CI jobs failing due to new/unexpected errors showing up. See: - https://edk2.groups.io/g/devel/message/116138 - https://github.com/linux-test-project/lcov/issues/209 - https://github.com/linux-test-project/lcov/issues/238 Signed-off-by: Oliver Steffen <osteffen@redhat.com>
* BaseTools/GenFw X64: Detect GOTCPRELX relaxations applied by LLDArd Biesheuvel2024-10-231-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GenFw relies on static ELF relocation tables emitted by the linker (via the --emit-relocs command line switch). These are different from the dynamic relocations that a dynamic loader uses: static relocations are emitted by the compiler/assembler, and consumed by the linker to construct the executable. Only when the load address is a priori unknown are dynamic relocations emitted, by the linker, in a format that the dynamic loader can consume. This distinction is relevant because only dynamic relocations cover the GOT, and so GOT based indirections are better avoided. Unfortunately, there are cases where the toolchain insists on emitting GOT based symbol references, and so we have to deal with them in one of 2 ways: - replace GOT based symbol references with direct references, so that the GOT entries themselves are no longer used, and can be ignored when generating the PE/COFF relocation tables (AARCH64 and RISCV64 take this approach); - infer the locations of the GOT slots from the references appearing in the code, and emit PE/COFF relocations for them so that their contents will be fixed up appropriately. The latter is the approach taken by GenFw for x86_64, which is the only feasible approach for its ISA, given that GOT slots can be used as memory operands in many different types of instructions, not all of which can be converted straight-forwardly. E.g., movq foo@GOTPCREL(%rip), %rax can always be converted into leaq foo(%rip), %rax whereas cmpq foo@GOTPCREL(%rip), %rax can only be converted under the 32-bit position dependent code model, into cmpq $foo, %rax and so the GOT references cannot be elided when generating position independent code, which is what GenFw requires. To remove the need for the linker to guess where the instructions start, the ELF psABI for x86_64 specifies a couple of relaxable alternatives for GOTPCREL, which are used to annotate particular classes of GOT referencing instructions that may be relaxed to their non-GOT counterparts. There is no specification for what --emit-relocs is supposed to produce, or whether or not its output is supposed to reflect such relaxations. ld.bfd and LLD behave differently in this regard, and the latter may emit R_X86_64_REX_GOTPCRELX relocations for MOV instructions that it already has relaxed into LEA instructions. This means the displacement in the instruction no longer refers to the GOT slot, but directly to the object itself, and emitting a relocation is not only unnecessary, but also harmful as the PE/COFF loader will corrupt the object when it applies the relocations at startup. Under the position independent code model, the only relaxation that the linker could have applied for a R_X86_64_REX_GOTPCRELX relocation is MOV to LEA, so detect whether the instruction is already LEA, and ignore the relocation if that is the case. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* BaseTools: Remove -Wno-unneeded-internal-declaration from CLANGDWARFMike Beaton2024-10-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Subsequent to updating the 'null' DEBUG macro to explicitly discard its expression, it is possible to remove this warning suppression from CLANGDWARF and still successfully compile its RELEASE build. Note that CLANGPDB did and does not have this warning suppressed, and so before updating the 'null' DEBUG macro, CLANGPDB RELEASE was not building successfully in recent versions of clang, but was stopping with the error: .../edk2/OvmfPkg/VirtioSerialDxe/VirtioSerial.c:28:22: error: variable &apos;EventNames&apos; is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration] STATIC CONST CHAR8 *EventNames[] = { ^ This change makes the two CLANG variants match with respect to this warning, and leaves the warning enabled which is considered a benefit as it has the potential to catch real coding errors Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
* BaseTools/SetupGit.py: Fix invalid choice 'edk2-test'Nhi Pham2024-10-091-1/+1
| | | | | | This fixes missing 'edk2-test' in the choices of the repo name option. Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
* BaseTools/CodeQl: Give preference to Plugin settingsAbdul Lateef Attar2024-10-091-5/+6
| | | | | | | | | | | | | | | For the CodeQl `AuditOnly` flag, prioritize Plugin settings over global settings. This patch adjusts the logic for the global `AuditOnly` setting, placing it before the Plugin setting code. This ensures that Plugin settings take precedence over global settings. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Joey Vagedes <joey.vagedes@gmail.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
* BaseTools: LinuxGcc5ToolChain: Run for GCC ToolchainOliver Smith-Denny2024-09-303-55/+66
| | | | | | | | | | | | | | | | | | The GCC5 TOOL_CHAIN_TAG is being deprecated in favor of GCC. LinuxGcc5ToolChain.py needs to be updated to find the correct ARM/AARCH64/RISCV/LOONGARCH64 compilers for the GCC TOOL_CHAIN_TAG, as well, otherwise it defaults to the system GCC, which is typically X64 based. In order to keep this backward and forward compatible, the plugin now checks for the substring "GCC" in the TOOL_CHAIN_TAG and will set either the "GCC5" or "GCC" env variables used by tools_def.template to find the GCC compiler for the requested architecture. This plugin is also renamed to drop the old GCC5. Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* BaseTools: Fix redefinition of UINT8_MAX in Decompress.c on XCODE5Mike Beaton2024-09-271-0/+2
| | | | | | | | | | | This is part of a sequence of commits to restore build on the XCODE5 toolchain. The definition is required on other toolchains, but on XCODE5 results in a macro redefined error (from the existing value 255) from /usr/include/stdint.h. Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
* 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/tools_def ARM: Disable stack protector with CLANGDWARFArd Biesheuvel2024-09-181-1/+1
| | | | | | | | | | | | | | | Clang insists on emitting a movt/movw pair into the function pro/epilogues to load the stack protector reference value from memory, and this movt/movw pair may turn out non-consecutively in the instruction stream. The resulting symbol reference cannot be fixed up by GenFw, as PE/COFF always treats movt/movw as a pair, and the ELF-to-PE conversion will therefore fail. Just disable the stack protector when using CLANGDWARF. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* BaseTools: Add Stack Cookie Support to MSVC and GCC IA32/X64/ARM/AARCH64Taylor Beebe2024-09-131-31/+34
| | | | | | | This patch directs MSVC and GCC to build stack cookie support into binaries. Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.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-1051-733/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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: Disable MSVC volatileMetadata for VS2019 and VS2022 for X64Ashraf Ali2024-09-061-6/+6
| | | | | | | | | | | | | | | Starting with Visual Studio 2019 version 16.10, the /volatileMetadata option is enabled by default when generating x64 code. This patch disables the /volatileMetadata option for x64 builds in both VS2019 and VS2022. We observed a slight increase in used space for the Firmware volumes in VS2019. Upon investigation, we found that VS2019 version 16.10 enabled this feature by default. Disabling /volatileMetadata helps reduce the used space by approximately 3.5KB by considering the 2 Firmware volumes (2KB uncompressed FV and 1.5KB of compressed FV) Signed-off-by: Ashraf Ali <ashraf.ali.s@intel.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/WinRcPath: Improve Performance.Joey Vagedes2024-08-041-10/+26
| | | | | | | | | | | | | | | | WinRcPath generally takes about 2 seconds to run, due to calling multiple .bat files behind the scenes. This change reduces this time to ~0 seconds due to the following changes: 1. It will attempt to load the path from the cache, which is located a $(WORKSPACE)/Conf/.rc_path. If the loading is a success and the rc_path still exists, it will use it. 2. If the cache did not exist, or the path provided by the cache does not exist, it will find the rc path via the .bat files. If that succeeds, it will write the path to the cache. Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
* BaseTools/Scripts/BinToPcd.py: Update regex strings to use raw strings.Antaeus Kleinert-Strand2024-08-011-2/+2
| | | | | | | | | | | | With Python 3.12 invalid escape sequences now generate warning messages. This change fixes the problem exposed by the warning message. ``` BaseTools/Scripts\BinToPcd.py:40: SyntaxWarning: invalid escape sequence BaseTools\Scripts\BinToPcd.py:46: SyntaxWarning: invalid escape sequence ``` Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
* CodeQlQueries.qls: Pin to the 1.1.0 codeq/cpp-queries packMichael Kubacki2024-07-314-1/+22
| | | | | | | | | | | | The codeql/cpp-queries pack used in CodeQlQueries.qls was versioned 1.1.0 for the CodeQL CLI v2.18.1 release currently used. https://github.com/github/codeql/blob/codeql-cli/v2.18.1/cpp/ql/src/qlpack.yml This change pins that pack version to prevent the CodeQL CLI and pack from getting out of sync until explicitly updated. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
* BaseTools: fix build error with TOOL_CHAIN_TAG VS2015 & VS2015x86wilson_chen2024-07-302-4/+12
| | | | | | | | | | | | | | | | | | Start the build with TOOL_CHAIN_TAG VS2015 by launch: Build -t VS2015 ERROR: Would get following build error message: 'c:\Program' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: '"c:\Program Files\Windows Kits\8.1\bin\x86\\rc.exe' : return code '0x1' Stop. Fix the build error, Tested : TOOL_CHAIN_TAG = VS2015 (>Build -t VS2015) TOOL_CHAIN_TAG = VS2015x86 (>Build -t VS2015x86) Signed-off-by: wilson_chen <wilson_chen@phoenix.com>
* BaseTools/tools_def CLANGDWARF: Always use -Oz in RELEASE modeArd Biesheuvel2024-07-281-3/+3
| | | | | | | | | | | | | | | | | | | | GCC5 and CLANGDWARF for IA32/X64 use -Os or -Oz as the optimization level, which agressively optimizes for the smallest possible object code. On AARCH64, RISCV64 and ARM, we use -O3 instead, which results in considerable image bloat, to the point where the Raspberry Pi 4 build in edk2-platforms does not even build with -D SECURE_BOOT_ENABLE. So let's align CLANGDWARF across all architectures, and use -Oz throughout. Note that O3 is still used for the linker, which build in LTO mode and therefore performs some code generation as well. This is deliberate: LLD does not support the Os/Oz optimization levels at all, and using Oz for the compile pass is sufficient to reduce the code size substantially. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* BaseTools/codeql: Update to CodeQL 2.18.1Michael Kubacki2024-07-263-9/+9
| | | | | | Updates to the latest CodeQL version to resolve query dependencies. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.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/GetMaintainer.py: Add GitHub username argumentMichael Kubacki2024-07-251-2/+9
| | | | | | | | | | | | Adds a new `-g` parameter so that output will also include the GitHub username. This change uses a simple regular expression as opposed to directly returning the original line from the file to make the extraction of GitHub usernames more robust to other changes on the line in the maintainers text file. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
* BaseTools: Move GnuNoteBti.bin to BaseToolsOliver Smith-Denny2024-07-232-1/+1
| | | | | | | | | This patch moves GnuNoteBti.bin from ArmPkg to BaseTools as it is used during the build by GCC. This removes an unnecessary dependency on ArmPkg from BaseTools and keeps build related files in BaseTools. Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* BaseTools: Move GccLto Files to BaseToolsOliver Smith-Denny2024-07-235-12/+88
| | | | | | | | | This moves the GccLto files from ArmPkg to BaseTools as they are files that are only used in the build. This removes an artificial dependency on ArmPkg from BaseTools and keeps build related files in BaseTools. Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* BaseTools/CodeQL: Removed unused static function queryMichael Kubacki2024-07-161-2/+0
| | | | | | | | | | | This query seems to produce a rate of false positives with some common patterns in edk2 like passing function pointers for callback. Due to the usage of `STATIC` instead of `static` particularly for functions, this query was rarely used in the past. It is removed here to prevent future false positives. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
* BaseTools/HostBasedUnitTestRunner: Promote Unittest error to CI fail.v-bhavanisu2024-07-151-0/+1
| | | | | | | | | | | Some unit tests would fail to execute or execute and not produce any output logs. In these cases, the only output would be in the CI Log as `UnitTest Execution Error`. A UnitTest Execution Error should be considered the same as a unit tests test failing. Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
generated by cgit (git 2.34.1) at 2025-02-23 19:44:05 +0000