When using function/data sections option from
gcc, some additional un-packed sections get created
move these to there correct placement if not already
included
sections seen on x86/x86_64/aarch64:
.gcc_except_table.efi_main
.bss.debugging
.gcc_except_table.* only appears on objcopy archs
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
Objcopy sometimes generates .rela.plt and .rela.data
sections for which their names are longer than the 8
characters limit of PE32
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
Date: Tue Feb 7 21:48:27 2023 +0000
ARM32/x86_64 lds: Force data segment align to 4KiB
Some newer versions of binutils can set invalid COMMONPAGESIZE
and MAXPAGESIZE values on these architectures
git fetch git.code.sf.net/u/gmbr3/gnu-efi arm-pagesize
git merge 89d55b364d
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
Some newer versions of binutils can set invalid COMMONPAGESIZE
and MAXPAGESIZE values on these architectures
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
Binutils 2.38 now supports efi-app-aarch64 so
to use this we must add a dummy reloc section
and remove the PE header definition from crt0
as this will conflict with the version added
by objcopy
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
Use ld commands DATA_SEGMENT_ALIGN and DATA_SEGMENT_END
Fixes binutils 2.39 warning:
/usr/bin/ld: warning: efi/fwup.so has a LOAD segment with RWX
permissions
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
The current ld script places .dynamic section right after .text, which
results in that one LOAD segment contains both data and code. Binutils
2.39 and later will throw a warning if RWX segments exist. Code and
data should be placed in different LOAD segments with different
permissions. This patch adds a gap between data and code sections which
is taken from the default ld script in riscv64.
Co-developed-by: Moody Liu <mooodyhunter@outlook.com>
Signed-off-by: Moody Liu <mooodyhunter@outlook.com>
Signed-off-by: Letu Ren <fantasquex@gmail.com>
According to README.gnuefi,
To build the sample EFI applications provided in subdirectory "apps",
simply invoke "make" in the toplevel directory (the directory
containing this README file). This should build lib/libefi.a and
gnuefi/libgnuefi.a first and then all the EFI applications such as a
apps/t6.efi.
The default target of top directory Makefile should be all instead of
gnuefi.
Signed-off-by: Letu Ren <fantasquex@gmail.com>
The assembly code uses fixed offsets into the jmp_buf and leaves an 8 byte
gap between the GPRs and the FPRs, but the jmp_buf structure was not laid
out to account for this so the code would overrun the jmp_buf by 8 bytes.
Found-by: Oskar Engen <oskar.engen@gmail.com>
Signed-off-by: Dwight Engen <dwight.engen@gmail.com>
Without the change there is no guarantee that .o files will be built
after directories are created for them and build fails as:
gcc -I/build/gnu-efi-code//lib ... -c lib/runtime/rtstr.c -o runtime/rtstr.o
Assembler messages:
Fatal error: can't create runtime/rtstr.o: No such file or directory
There's little reason not to derive the RISCV64 version of efibind.h
from the AARCH64 version, especially as the current version is missing
required macros such as EFI_DRIVER_ENTRY_POINT() which breaks the
compilation of some drivers.
The only major difference we introduce from AARCH64 is to consider
that any toolchain that supports RISCV64 is modern enough to support
<stdint.h>. Also, as we preserve the added definition for BOOLEAN,
we guard it with an ifndef in anticipation of MSVC RISCV64 support.
We validated these changes by confirming that they now allow gnu-efi
to be used to compile a set of UEFI drivers for RISCV64.
Acoording to what the spec says about the number of sybols [1]:
"This value should be zero for an image because COFF debugging
information is deprecated."
Changing as if not zero it causes problems to llvm-objcopy. This
affects only the architectures where COFF is not supported by objcopy
and where we build the PE header via assembly code.
[1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
When compiling for x64, Visual Studio 2019's Code Analysis produces the following warnings:
C:\Projects\gnu-efi\lib\print.c(1380): warning C26451: Arithmetic overflow: Using operator '+' on a 4 byte value and then casting the result to a 8 byte value. Cast the value to the wider type before calling operator '+' to avoid overflow (io.2).
C:\Projects\gnu-efi\lib\smbios.c(47): warning C26451: Arithmetic overflow: Using operator '+' on a 4 byte value and then casting the result to a 8 byte value. Cast the value to the wider type before calling operator '+' to avoid overflow (io.2).
C:\Projects\gnu-efi\lib\str.c(289): warning C26451: Arithmetic overflow: Using operator '-' on a 4 byte value and then casting the result to a 8 byte value. Cast the value to the wider type before calling operator '-' to avoid overflow (io.2).
Fix these by adding an explicit cast to UINTN.
Add definitions for the EFI device tree table, as specified in UEFI
specification 2.9 (March 2021).
Signed-off-by: Alfonso Sánchez-Beato <alfonso.sanchez-beato@canonical.com>
The size of FrameBufferAddr is architecture dependent. Add the missing
definition for the riscv64 architecture.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
EFI_ERROR(EFI_NOT_STARTED) is true. So we can simplify
(EFI_ERROR(rc) && rc == EFI_NOT_STARTED)
to
(rc == EFI_NOT_STARTED)
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
These values are from the UEFI specification version 2.9.
Signed-off-by: David Michael <fedora.dm0@...>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
The hidden visibility #pragma in inc/arm/efibind.h was meant to inform
the compiler that symbols with external linkage are never exported from
shared libraries [and thus never preempted] when executing in UEFI context
(since UEFI does not support shared libraries). This allows the compiler to
generate relative symbol references instead of GOT entries, which is much more
efficient since the latter need to be relocated before invoking the entry
point of the UEFI app.
However, as it turns out, this pragma is leaking into other code that does
not run in UEFI context, but simply needs to access data structures that
UEFI defines. So make the pragma dependent on whether we are building with
-ffreestanding, which is only used for bare metal code such as UEFI.
Last-Update: 2018-08-24
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Elder versions of sbsigntool failed to build on armhf without the patch,
cf. https://launchpad.net/ubuntu/+source/gnu-efi/3.0.8-0ubuntu1~16.04.1
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
As per the PE format specification, relocation blocks must be aligned on 32-bit boundaries. Fix the dummy relocations to obey the alignment constraints.
