summaryrefslogtreecommitdiffstats
path: root/BaseTools
Commit message (Collapse)AuthorAgeFilesLines
* BaseTools:Expression.py Adding a check for missing '}' in the parserpg/proximity_domain_reworkDoug Flick6 days1-1/+1
| | | | | | | This check is to catch cases where a missing '}' exists in a dec or dsc file. Signed-off-by: Doug Flick <dougflick@microsoft.com>
* BaseTools:Expression.py Add Assertion for PCD with value {}Doug Flick6 days1-0/+2
| | | | | | | This adds an assertion to the PCD class in the Expression.py file to check for zero-byte PCDs. Signed-off-by: Doug Flick <dougflick@microsoft.com>
* BaseTools:Expression.py Size used before InitDoug Flick6 days1-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The following example fails to be parsed correctly due to Size being used in the outer scope but initialized in the inner scope ``` gPlatformPkgTokenSpaceGuid.PcdSecureBootDbxBinaryFile|{} ``` Problematic code: ```python for Item in NewPcdValueList: Size = 0 # .... if Size > 0: PcdValue = '{' + ', '.join(AllPcdValueList) + '}' ```` Signed-off-by: Doug Flick <dougflick@microsoft.com>
* BaseTools: Fix FMMT Compress wrong behaviorYuwei Chen9 days1-1/+1
| | | | | | | | | | | | | | | | When using the replace function, if the replaced file located in a compress section, then the tool will re-build the section. As the compress status set in the wrong place, in some situation, the compress will do twice times which is a wrong behavior. This patch is used to fix this issue. Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Ashraf Ali S <ashraf.ali.s@intel.com> Signed-off-by: Yuwei Chen <yuwei.chen@intel.com>
* BaseTools: Dump library dependency chain on build failureRay Ni12 days1-2/+14
| | | | | | | | | | | | | | | | | | | | | When a module M depends on L1, which depends on L2, which depends on L3, the build fails when the library instance of L3 cannot be found according to the library class-instance mapping configuration specified in the DSC file. When such failure happens, the build tool only prints that the instance of L3 required by module M cannot be found. But it does not tell how L3 is required by M. The change enhances build tool to print the entire dependency chain when such failure happens. With the change, the new error message will be as follows: <dsc-path>(...): error 4000: Instance of library class [L3] is not found for module [M], [L3] is: consumed by <instance of L2> consumed by <instance of L1> Signed-off-by: Ray Ni <ray.ni@intel.com>
* BaseTools/build: Reduce special FV full to warningMichael D Kinney2025-03-311-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If an FV_SPARE_SPACE_THRESHOLD is enabled and an FV is 100% full with 0 bytes free, then this is likely a special FV that may have alignment requirements for the FFS file for both the start address and the length and the FFS file consumes all the available FV space. Reduce FV_SPARE_SPACE_THRESHOLD from an error to a warning if this FV 0 bytes free condition is detected. PR #10828 introduced the generation of these error conditions for an FV with large alignment requirements. The pad region before the aligned FFS file used to be counted as free space even though it could never be used due to the alignment requirements. There was actually no free space available. PR #10828 fixed the free space calculation to properly show it as 0 bytes free, and this change then caused build error when FV_SPARE_SPACE_THRESHOLD feature was enabled. The reduction to a warning for this condition allows the build to complete with errors and also provides a build log warning message for review. Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools/FMMT: Fix GUID Tool Not Found the Shell Script IssueJason1 Lin2025-03-261-3/+3
| | | | | | | | | | | | | | | | | | | - FMMT tool would use the "PATH" environment variable for locating the required GUID tool. - On Windows-like system, batch file not found in the "PATH" environment variable when "shell=False". - This issue required commands to include program extensions or absolute paths. - This patch sets "shell=True" to extend the support for batch files, including scripts in BinWrappers under BaseTools. - Converted input commands from lists to strings to ensure proper argument interpretation in POSIX-like shell scripts. Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
* BaseTools: Fix missing module PCD in compile information of build reportZhiguang Liu2025-03-251-1/+1
| | | | | | Module PCD in compile information is missed in module_report.json Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* BaseTools/GenFv: Ensure the minimum pad file size for the FV with VTFPhil Noh2025-03-221-14/+29
| | | | | | | | | | | | | | | | | | | | In case of the FV with VTF, the left size should be enough to add the minimum pad file size (EFI_FFS_FILE_HEADER, 0x18). It prevents the build error, "GenFv: ERROR 0006: invalid FFS file header checksum" caused by the pad file overwriting some header data in VTF. This includes these updates for CalculateFvSize() function. 1. If NumBlocks is not defined, ensure the minimum pad file size for the left size (if the pad file is required as VTF is not bottom aligned at end of block, insert EFI_FFS_FILE_HEADER to ensure the pad file size) 2. If NumBlocks is defined, report more clear error message (the required fv image size = 0x%x. the set fv image size = 0x%x. Free space left is not enough to add a pad file (0x18)) 3. Remove MaxPadFileSize, which is reported when the taken size is same as the total size. It can not be the actual left size to add an FFS file. It causes confusion when referring to the build log (FV Space Information) Signed-off-by: Phil Noh <Phil.Noh@amd.com>
* BaseTools: Fix Debug Macro Checking to Include Scanning FilesJason1 Lin2025-03-131-1/+1
| | | | | | | | | | | | | | - In the commit 42a141800c0c26a09d2344e84a89ce4097a263ae there was a misuse of "is_dir" method. - Treating it as an object rather than function call, which caused if-condition to always as "false". - No files would be added to scanning list due to incorrect usage. - This patch corrects the issue by properly using "is_dir()". Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
* BaseTools: Disable VS2019/2022 ARM/AARCH64 Stack CookiesOliver Smith-Denny2025-03-121-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | VS2019/VS2022 ARM/AARCH64 is not a widely used toolchain, for one thing edk2 can't be built with it, it will break. Downstream platforms rarely use it and if they do, they must have heavy edits in order to support building edk2. In particular, edk2 does not have support for the assembly files that this toolchain uses fully. As a result, the corresponding StackCheckLib does not have the assembly file needed to satisfy the definitions the compiler expects. Unfortunately, the VS ARM/AARCH64 compiler has a different ABI than the IA32/X64 VS toolchain for stack cookies, so this also needs more investigation. For now, disable stack cookie checking in VS ARM/AARCH64 as this does not affect many platforms. However, it does allow for the use case reported in the bug mentioning this, which is building a shell and attempting to boot to it. When VS ARM/AARCH64 support is revisited in edk2 (or if there is a clean way to add stack cookie support without the full support), this will be revisted. Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
* BaseTools/Source/C: Disable VS flexible array member warningMichael D Kinney2025-03-121-1/+8
| | | | | | | | | | | | | Add /wd4200 to all visual studio builds of C tools in BaseTools. This disables warnings for use of flexible array members that are allowed in edk2 include files. Some tools use include files from MdePkg that use flexible array members. This matches the warning disables used to build structured PCD in BaseTools/Source/Python/Workspace/DscBuildData.py where flexible array members are more widely used. Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools: Add BUILDRULEFAMILY for CLANGDWARFVishal Oliyil Kunnil2025-03-112-0/+14
| | | | | | | | | | | | | | | | | Commit c6f47e6 removed BUILDRULEFAMILY for CLANGDWARF. Adding CLANGDWARF back as a BUILDRULEFAMILY to match CLANGPDB. Add CLANGDWARF specific build rules - based on GCC, and remove steps not required for CLANGDWARF. Remove following irrelevant steps and logs: ... "objcopy not needed ..." "--strip-unneded ..." "--add-gnu-debuglink ..." ... Signed-off-by: Vishal Oliyil Kunnil <quic_vishalo@quicinc.com>
* DebugMacroCheck: Do not show progress bar with zero itemsMichael Kubacki2025-03-061-0/+3
| | | | | | | | In the case that the total provided to the `_show_progress()` function is zero, do not show a progress bar to prevent aborts `ZeroDivisionError` when calculating the progress percentage. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
* BaseTools: Add @verbatim as allowed Doxygen tagRebecca Cran2025-02-042-2/+2
| | | | | | | Per the discussion in https://github.com/tianocore/edk2/pull/6476, update Ecc code to allow the @verbatim Doxygen tag. Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
* BaseTools: Add /DRIVER to CLANGPDB link flagsDionna Glaze2025-02-031-6/+6
| | | | | | This quiets the warning reported in Issue #10637. Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
* BaseTools/AutoGen: GenMake response file quotes stringsMichael D Kinney2025-02-021-3/+14
| | | | | | | | | | | If command line options are moved into a response file of a GCC family build, then the file path separators are converted from '\' to '/'. However, this can corrupt command line options that are quoted strings. Update GenMake to no convert '\' to '/' in quoted strings. Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
* BaseTools/tools_def: Remove no-warn-rwx-segments linker optionsArd Biesheuvel2025-02-021-8/+3
| | | | | | | | | | | | | | The linker option 'no-warn-rwx-segments' breaks both the LLVM linker and versions of the binutils ld.bfd linker prior to 2.39. Now that the ELF image is made up of separate R-X and RW- segments, this warning is no longer emitted and so there is no longer a need to suppress it either. While at it, move GCC_DLINK_FLAGS_COMMON (which is not common but only used by Ia32 and X64) into its only user so it can be dropped. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* BaseTools/Scripts/GccBase.lds: Use separate R-W and RW- ELF segmentsArd Biesheuvel2025-02-021-3/+11
| | | | | | | | | | | | To prevent the ELF linkers from complaining about emitted ELF segments that require both writable and executable permissions, define two separate R-X and RW- ELF segments, and emit the output sections explicitly into those segments as appropriate. Note that this has no bearing on the PE image, and using a single RW- segment would probably be fine too. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* BaseTools/Scripts: Merge GCC and Clang ELF linker scriptsArd Biesheuvel2025-02-023-94/+4
| | | | | | | | | | | | | | The original reason for creating a separate version of the ELF linker script for Clang was the difference between COMMONPAGESIZE and MAXPAGESIZE, which can we provided on the command line to the respective linkers (ld.bfd versus lld). That difference no longer exists, and both use COMMONPAGE_SIZE. So there is no longer a need to maintain a fork, which has already been going out of sync with the original for no good reason. So merge the two and call it GccBase.lds Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* BaseTools/Scripts/ClangBase.lds: Move .entry into .text sectionArd Biesheuvel2025-02-021-4/+1
| | | | | | | | | | | | | | | | The GccBase.lds and ClangBase.lds ELF linker scripts have been laid out very carefully to ensure that the memory mappings of .text and .data are such that they can be preserved in the PE/COFF memory image. This removes the need to update any place-relative ELF relocations when generating the PE/COFF image, making its job much easier, and potentially allowing it to disregard static ELF relocations altogether, and rely solely on dynamic ELF relocations. Adding an arbitrary .entry section before .text breaks those assumptions, so instead of emitting it as a separate section, move its payload to the start of .text. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* 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>
generated by cgit v1.2.3 (git 2.46.0) at 2025-04-20 09:29:22 +0000