Guard the macros by the compilers they should explicitly apply to and
add a #error in case the compiler has no alignment directive defined,
as ignoring alignment is likely to produce runtime errors.
Also prefer _MSC_VER to _MSC_EXTENSIONS, as _MSC_EXTENSIONS may not
always be defined by the MSVC compiler.
Signed-off-by: Pete Batard <pete@akeo.ie>
As explained at https://stackoverflow.com/a/49830956/1069307, 'asm' is a GNU
extension that will produce an error when using a non GNU standard like -std=c11.
With recent commit 9b1e06cd0c having fixed our use
of -std=c11, the MIPS build failed with the error above.
With this sorted, we also re-enable the MIPS gcc build in GitHub Actions.
This was hopefully just a typo that has been cargo-culted around the codebase.
It certainly confuses the Red Hat license checker and makes the code copyright
clear.
For wildly unknown reasons, EFI Boot Services includes CopyMem() and
SetMem() functions, and they are marked as EFIAPI functions.
This patch marks gnu-efi's CopyMem() and SetMem() as EFIAPI functions,
and makes their exposed API match the misguided nonsense in the EFI
spec, so that they can be used there in a test environment.
Signed-off-by: Peter Jones <pjones@redhat.com>
Also add EXEC_PREFIX and INCLUDEDIR variables
This was requested by fwupd-efi, to be able
to retrieve the version number of gnu-efi
so we can detect features
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
The whole gnu-efi project is licensed under BSD license, see [1].
However some of the RISC-V codes have conflict license identifiers:
- Some mention GPL-2.0+ in the SPDX license part, but the long license
header indicates it's actually BSD and GPL-2.0+ dual-licensed
- Some mention GPL-2.0+ in the SPDX license part only
- Some do not have any license indication
To have a matching license with the whole project, this commit updates
all RISC-V codes to have the correct SPDX license identifiers
(GPL-2.0+ or BSD dual-license).
Link: https://sourceforge.net/p/gnu-efi/ [1]
Signed-off-by: Bin Meng <bmeng@tinylab.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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>
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.
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>
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>
