Allows substituting the GUID with the human-readable `TtyTerm` tag, akin
to other terminal types
Signed-off-by: Filip Lewinski <filip.lewinski@3mdeb.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
