summaryrefslogtreecommitdiff
path: root/BaseTools/Source/C
AgeCommit message (Collapse)AuthorFilesLines
5 daysBaseTools: Fix redefinition of UINT8_MAX in Decompress.c on XCODE5Mike Beaton1-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>
13 daysBaseTools: Update RETURN_ERROR Macro in BaseTypes.hAbdul Lateef Attar1-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>
2024-07-26BaseTools: Move MEMORY_TYPE_* Defines to EFI_MEMORY_TYPE EnumDmitry Antipov1-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>
2024-02-26BaseTools: Update keybaord map based on UEFI spec 2.10Yi Li1-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>
2023-12-21BaseTools/GenFw: Correct offset when relocating an ADRJake Garver1-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>
2023-11-06BaseTools: GenFw: auto-set nxcompat flagJoey Vagedes1-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>
2023-09-25BaseTools/GenFw: Add support for LOONGARCH64 relax relocationDongyan Qian2-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>
2023-09-18BaseTools: Remove logic to create AP waking vector in GenFvZhiguang Liu1-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>
2023-06-01BaseTools: remove duplicate includes: IndustryStandard/*.hGerd Hoffmann7-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>
2023-06-01BaseTools: remove duplicate includes: IndustryStandard/PeImage.hGerd Hoffmann1-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>
2023-06-01BaseTools: switch from EFI_IMAGE_MACHINE_* to IMAGE_FILE_MACHINE_*Gerd Hoffmann7-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>
2023-06-01BaseTools: drop IMAGE_FILE_MACHINE_ARM hacksGerd Hoffmann1-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>
2023-06-01BaseTools: remove duplicate includes: IndustryStandard/Acpi*.hGerd Hoffmann8-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>
2023-06-01BaseTools: remove duplicate includes: <arch>/ProcessorBind.hGerd Hoffmann9-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>
2023-06-01BaseTools: remove WinNtInclude.hGerd Hoffmann6-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>
2023-05-08BaseTools: use threading.current_thread in NmakeSubdirs.pyRebecca Cran1-1/+1
threading.currentThread is a deprecated alias for threading.current_thread, and causes a warning to be displayed when it's called. Update NmakeSubdirs.py to use the latter method instead. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2023-04-07BaseTools/GenFw: Add DllCharacteristicsEx field to debug dataArd Biesheuvel3-15/+55
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4405 The PE/COFF spec describes an additional DllCharacteristics field implemented as a debug directory entry, which carries flags related to which control flow integrity (CFI) features are supported by the binary. So let's add this entry when doing ELF to PE/COFF conversion - we will add support for setting the flags in a subsequent patch. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com> Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com> Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2023-04-07BaseTools/GenFw: Parse IBT/BTI support status from ELF noteArd Biesheuvel2-0/+59
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4405 When performing ELF to PE/COFF conversion, parse any notes sections to decide whether the image supports forward CFI landing pads. This will be used to set the associated DllCharacteristicsEx flag in a subsequent patch. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com> Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com> Acked-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2023-04-06BaseTools: Update antlr makefile to use cc by defaultRebecca Cran1-5/+0
Update the antlr makefile to remove the explicit setting of CC to either clang or gcc. This causes it to use /usr/bin/cc or whatever the user has set $(CC) to. This removes the last dependency on gcc for BaseTools. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2023-04-05BaseTools: Build against C++14 when building with clangRebecca Cran1-1/+1
clang 17 defaults to C++17, where the 'register' keyword is deprecated and the warning changed to an error. To avoid build errors, compile against C++14 by specifying '-std=c++14' in CXXFLAGS. Signed-off-by: Rebecca Cran <rebecca@quicinc.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2023-04-05BaseTools: Allow users to build with clang using CC=clang CXX=clang++Rebecca Cran5-18/+22
In https://bugzilla.tianocore.org/show_bug.cgi?id=2842 clang support was added by having users specify "make CXX=llvm" when building BaseTools. The Makefile then sees that and sets CC=$(CLANG_BIN)clang and CXX=$(CLANG_BIN)clang++. That requires that the executables 'clang' and 'clang++' exist and for example aren't named 'clang-17' and 'clang++-17'. Also, it's an unusual way of specifying the compiler, since many users will expect to be able to override CC and CXX on the make command line. Rework the BaseTools Makefiles removing the 'BUILD_' prefix (BUILD_CC and BUILD_CXX) and using the standard name 'LDFLAGS' instead of 'LFLAGS'. This allows clang to be used by running 'make -C BaseTools CC=clang CXX=clang++'. Signed-off-by: Rebecca Cran <rebecca@quicinc.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2023-04-05BaseTools: Allow users to specify compiler to use with make CC= CXX=Rebecca Cran8-58/+58
In https://bugzilla.tianocore.org/show_bug.cgi?id=2842 clang support was added by having users specify "make CXX=llvm" when building BaseTools. The Makefile then sees that and sets CC=$(CLANG_BIN)clang and CXX=$(CLANG_BIN)clang++. That requires that the executables 'clang' and 'clang++' exist and for example aren't named 'clang-17' and 'clang++-17'. Also, it's an unusual way of specifying the compiler, since many users will expect to be able to override CC and CXX on the make command line. Rework the BaseTools Makefiles removing the 'BUILD_' prefix (BUILD_CC and BUILD_CXX) and using the standard name 'LDFLAGS' instead of 'LFLAGS'. This allows clang to be used by running 'make -C BaseTools CC=clang CXX=clang++'. Signed-off-by: Rebecca Cran <rebecca@quicinc.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2023-04-03BaseTools/VfrCompile: Fix potential buffer overwritesMichael Kubacki2-7/+7
While more portable methods exist to handle these cases, this change does not attempt to do more than fix the immediate problem and follow the conventions already established in this code. `snprintf()` is introduced as the minimum improvement apart from making the buffers larger. Fixes the following CodeQL alerts: 1. Failure on line 2339 in BaseTools/Source/C/VfrCompile/Pccts/antlr/gen.c - Type: Potentially overrunning write - Severity: Critical - Problem: This 'call to sprintf' operation requires 17 bytes but the destination is only 16 bytes. 2. Failure on line 2341 in BaseTools/Source/C/VfrCompile/Pccts/antlr/gen.c - Type: Potentially overrunning write - Severity: Critical - Problem: This 'call to sprintf' operation requires 17 bytes but the destination is only 16 bytes. 3. Failure on line 1309 in BaseTools/Source/C/VfrCompile/Pccts/antlr/main.c - Type: Potentially overrunning write - Severity: Critical - Problem: This 'call to sprintf' operation requires 25 bytes but the destination is only 20 bytes. 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: Sean Brogan <sean.brogan@microsoft.com> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
2023-03-24BaseTools: Replace duplicate __PcdSet prototype with __PcdGetRebecca Cran1-7/+6
Replace the duplicate __PcdSet prototype in PcdValueCommon.h with the prototype for __PcdGet. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2023-03-24BaseTools: Source/C/Common: Fix doc block locations and convert to DoxygenRebecca Cran29-4065/+2072
Move the documentation blocks from between the parameter list and function body to above the function. Convert all the documentation blocks to Doxygen format. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2023-02-07BaseTools: remove useless dependency on libuuidThierry LARONDE2-10/+1
Signed-off-by: Thierry LARONDE <tlaronde@polynum.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2022-12-30BaseTools: Use BUILD_CC when checking gcc version in DevicePathJake Garver1-1/+1
When checking the version in DevicePath's Makefile, use BUILD_CC instead of assuming "gcc". BUILD_CC is set in header.makefile and is the compiler that will actually be used to build DevicePath. It defaults to "gcc", but may be overridden. Signed-off-by: Jake Garver <jake@nvidia.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2022-11-09BaseTools: Fix wrong type of arguments to formatting functionsMichael Kubacki5-8/+8
Fixes issues found with the cpp/wrong-type-format-argument CodeQL rule in BaseTools. Reference: https://cwe.mitre.org/data/definitions/686.html The following CodeQL errors are resolved: 1. Check failure on line 1115 in BaseTools/Source/C/EfiRom/EfiRom.c - This argument should be of type 'int' but is of type 'char *'. - This argument should be of type 'int' but is of type 'signed char *'. 2. Check failure on line 359 in BaseTools/Source/C/GenFw/Elf32Convert.c - This argument should be of type 'CHAR8 *' but is of type 'unsigned int'. 3. Check failure on line 1841 in BaseTools/Source/C/GenFw/Elf64Convert.c - This argument should be of type 'unsigned int' but is of type 'unsigned long long'. 4. Check failure on line 1871 in BaseTools/Source/C/GenFw/Elf64Convert.c - This argument should be of type 'unsigned int' but is of type 'unsigned long long'. 5. Check failure on line 2400 in BaseTools/Source/C/GenFv/GenFvInternalLib.c - This argument should be of type 'unsigned long long' but is of type 'unsigned int'. 6. Check failure on line 1099 in BaseTools/Source/C/GenFw/Elf64Convert.c - This argument should be of type 'CHAR8 *' but is of type 'unsigned int'. 7. Check failure on line 1098 in BaseTools/Source/C/GenSec/GenSec.c - This argument should be of type 'CHAR8 *' but is of type 'char **'. 8. Check failure on line 911 in BaseTools/Source/C/GenSec/GenSec.c - This argument should be of type 'CHAR8 *' but is of type 'char **'. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Sean Brogan <sean.brogan@microsoft.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
2022-11-08BaseTools/Source/C: Use /Z7 instead of /Zi for host toolsMichael D Kinney5-14/+12
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4139 Update ms.common and *.mak files to use /Z7 instead of /Zi to embed symbol information in obj files for host tools built with VS compilers. This prevents vcxxx.pdb files from being generated in the root of the local edk2 repository or in BaseTools directories. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2022-10-22BaseTools: Fixed the multiple pairs brackets issue in GenFvChao Li1-3/+3
If operation Werro is turned on when compiling BaseTools, the multi-brackets warning will be reported. This issue is comes from on of the LoongArch enabled patche. Removed extra pairs brackets to fix it. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4111 Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Chao Li <lichao@loongson.cn> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2022-10-16BaseTools: Remove duplicated words in C toolsPierre Gondois4-7/+7
In an effort to clean the documentation of the above package, remove duplicated words. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
2022-10-14BaseTools: Add LoongArch64 binding.Chao Li2-0/+83
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4053 Add LoongArch64 ProcessorBin.h and add LoongArch to Makefiles. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Chao Li <lichao@loongson.cn> Co-authored-by: Baoqi Zhang <zhangbaoqi@loongson.cn> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2022-10-14BaseTools: Update GenFw/GenFv to support LoongArch platform.Chao Li7-33/+636
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4053 C code changes for building EDK2 LoongArch platform. For definitions of PE/COFF and LOONGARCH relocation types, see the "Machine Types" and "Basic Relocation Types" sections of this URL for LOONGARCH values: https://docs.microsoft.com/en-us/windows/win32/debug/pe-format Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Chao Li <lichao@loongson.cn> Co-authored-by: Dongyan Qian <qiandongyan@loongson.cn> Co-authored-by: Baoqi Zhang <zhangbaoqi@loongson.cn> Co-authored-by: Yang Zhou <zhouyang@loongson.cn> Co-authored-by: Xiaotian Wu <wuxiaotian@loongson.cn> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2022-10-02BaseTools/VolInfo: Update file and section type stringsKonstantin Aladyshev1-6/+6
Change SMM to MM in naming according to the recent PI specifications. Remove trailing whitespaces in some strings. Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2022-10-02BaseTools/VolInfo: Update copyright informationKonstantin Aladyshev1-0/+1
Add Konstantin Aladyshev to the copyright header. Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2022-10-02BaseTools/VolInfo: Parse apriori filesKonstantin Aladyshev1-0/+74
Output file GUIDs from the DXE and PEI apriori files. Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2022-10-02BaseTools/VolInfo: Increase GUID base name stringKonstantin Aladyshev1-3/+1
The current string lenght (=60) is not enough for cases where basename is a path to Build folder. Drop custom define and use MAX_LINE_LEN from the BaseTools codebase instead. Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2022-10-02BaseTools/VolInfo: Fix EFI_SECTION_GUID_DEFINED parsingKonstantin Aladyshev1-4/+4
Currently 'PutFileImage' function is called with arguments that are not advanced on each section parsing. This would lead to an error if EFI_SECTION_GUID_DEFINED is not the first in a file. The same mistake is present in the parsing of CRC32 guided section case. Use correct arguments to fix the issue. Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2022-10-02BaseTools/VolInfo: Correct buffer for GenCrc32 toolKonstantin Aladyshev1-0/+7
If the guided section was encoded with GenCrc32 tool the resulting 'EFI_GUID_DEFINED_SECTION.DataOffset' field points to the start of the meaningfull data that follows the CRC32 value. But if we want to decode the section with GenCrc32 tool we need to provide a buffer that includes the CRC32 value itself. Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2022-09-15BaseTools: 64bit FSP FV map file cannot be created correctlyKuo, Ted1-1/+1
https://bugzilla.tianocore.org/show_bug.cgi?id=4035 64bit FSP FV map file cannot be created correctly when using CLANG compiler. When compiling 64bit FSP with CLANG, there is no prefix symbol '_' added to function name. Hence FSP FV map file cannot be created properly. Updated the if condition for CLANG in GenFv to get the issue fixed. Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Lee Hamel <lee.m.hamel@intel.com> Signed-off-by: Ted Kuo <ted.kuo@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2022-09-08BaseTools/GenFw AARCH64: Convert more types of explicit GOT referencesArd Biesheuvel1-0/+35
Rebecca reports that builds of AArch64 DSCs that involve PIE linking when using ELF based toolchains are failing in some cases, resulting in an error message like bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported symbol type. For example, absolute and undefined symbols are not supported. The reason turns out to be that, while GenFw does carry some logic to convert GOT based symbol references into direct ones (which is always possible given that our ELF to PE/COFF conversion only supports fully linked executables), it does not support all possible combinations of relocations that the linker may emit to load symbol addresses from the GOT. In particular, when performing a non-LTO link on object code built with GCC using -fpie, we may end up with GOT based references such as the one below, where the address of the GOT itself is taken, and the offset of the symbol in the GOT is reflected in the immediate offset of the subsequent LDR instruction. 838: adrp x0, 16000 838: R_AARCH64_ADR_PREL_PG_HI21 _GLOBAL_OFFSET_TABLE_ 83c: ldr x0, [x0, #2536] 83c: R_AARCH64_LD64_GOTPAGE_LO15 _gPcd_BinaryPatch_PcdFdBaseAddress The reason that we omit GOT based symbol references when performing ELF to PE/COFF conversion is that the GOT is not described by static ELF relocations, which means that the ELF file lacks the metadata to generate the PE/COFF relocations covering the GOT table in the PE/COFF executable. Given that none of the usual motivations for using a GOT (copy on write footprint, shared libraries) apply to EFI executables in the first place, the easiest way around this is to convert all GOT based symbol address loads to PC relative ADR/ADRP instructions. So implement this handling for R_AARCH64_LD64_GOTPAGE_LO15 and R_AARCH64_LD64_GOTOFF_LO15 relocations as well, and turn the LDR instructions in question into ADR instructions that generate the address immediately. This leaves the reference to _GLOBAL_OFFSET_TABLE_ itself, which is what generated the error to begin with. Considering that this symbol is never referenced (i.e., it doesn't appear anywhere in the code) and is only meaningful in combination with R_*_GOT_* based relocations that follow it, we can just disregard any references to it entirely, given that we convert all of those followup relocations into direct references. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Rebecca Cran <rebecca@bsdio.com> Acked-by: Leif Lindholm <quic_llindhol@quicinc.com> Acked-by: Bob Feng <bob.c.feng@intel.com>
2022-08-28BaseTools: Fix DevicePath GNUmakefile for macOSedk2-stable202208Rebecca Cran1-0/+2
On macOS, /usr/bin/gcc is clang, and so doesn't have the -Wno-error=stringop-overflow flag that was added for gcc 12. Update the GNUmakefile for DevicePath to skip setting that on macOS. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
2022-08-19BaseTools/Source/C/GenSec: Fix EFI_SECTION_FREEFORM_SUBTYPE_GUID headerMichael D Kinney1-1/+1
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4021 When the size of a EFI_SECTION_FREEFORM_SUBTYPE_GUID section required the use of EFI_FREEFORM_SUBTYPE_GUID_SECTION2 header, set the section type to EFI_SECTION_FREEFORM_SUBTYPE_GUID. Cc: Leif Lindholm <llindhol@qti.qualcomm.com> Cc: Andrew Fish <afish@apple.com> Cc: Konstantin Aladyshev <aladyshev22@gmail.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Acked-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Leif Lindholm <llindhol@qti.qualcomm.com>
2022-08-08Basetools/GenFw: Allow AARCH64 builds to use the --prm flagJose Marinho1-3/+3
The GenFw invocation with the --prm flag was previously reserved for X64. AArch64 platforms, built with GCC5, can also deploy PRM modules, hence the --prm flag is also applicable in builds targeting the AARCH64 architecture. This commit enables the --prm flag to be used for EDK2 builds targeting AARCH64. Signed-off-by: Jose Marinho <jose.marinho@arm.com> Signed-off-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
2022-08-06BaseTools/GenSec: Support EFI_SECTION_FREEFORM_SUBTYPE_GUID sectionsKonstantin Aladyshev1-2/+169
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2022-08-06BaseTools/VolInfo: Parse EFI_SECTION_FREEFORM_SUBTYPE_GUID headerKonstantin Aladyshev1-1/+9
Print 'SubtypeGuid' field from the EFI_FREEFORM_SUBTYPE_GUID_SECTION structure. This value describes the raw data inside the section. Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Bob Feng<bob.c.feng@intel.com>
2022-08-06BaseTools/VolInfo: Show FV section boundariesKonstantin Aladyshev1-0/+2
Currently there is no labels for start and end of the EFI_SECTION_FIRMWARE_VOLUME_IMAGE type section. Therefore it is not possible to see where the FV section ends and another section starts. Add labels for start and end of the FV sections to fix the issue. Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2022-08-06BaseTools/GenSec: Fix typoKonstantin Aladyshev1-1/+1
Fix typo in the help message. Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2022-07-27BaseTools/VolInfo: Show encapsulation sectionsKonstantin Aladyshev1-0/+6
Currently there is no labels for start and end of the encapsulation sections. Therefore it is not possible to see where the encapsulation section ends and another section starts. Add labels for start and end of encapsulation sections to fix the issue. Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2022-07-24BaseTools/VolInfo: Correct EFI_SECTION_VERSION displayKonstantin Aladyshev1-2/+9
- Correct typo in print statement, - "BuildNumber" field is UINT16, therefore it needs "0x%04X" format modifier, - "VersionString" field is CHAR16, therefore the input data should be processed to be displayed with "%s" printf modifier. Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
generated by cgit v1.1 at 2024-10-02 22:31:57 +0000