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.
For each va_start() there must be a va_end().
Correct LibInstallProtocolInterfaces() and
LibUninstallProtocolInterfaces().
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
GrowBuffer() expects that parameter Status is initialized.
LibGetVariableAndSize() currently passes random data from the stack.
Initialize variable Status.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Per https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/BaseMemoryLib.h
"(CopyMem) must handle the case where SourceBuffer overlaps DestinationBuffer".
Having the gnu-efi version of CopyMem differ from the EDK2 version can lead to
extremely hard to troubleshoot issues as well as very unexpected results. So
make sure our version follows the same guidelines.
Having to add specific arch include paths and then <gnu-efi>/lib
to be able to use gnu-efi in an application is annoying.
This patch ensures that the library itself takes care of including
the relevant headers, and that one needs only to add <gnu-efi>/inc
in their include path to be able to use gnu-efi.
Per https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/PrintLib.h
AsciiPrint() is the official name of APrint() so declare it as such and define
an APrint alias for compatibility.
Also add an AsciiVSPrint() to print a formatted ASCII string to a buffer using
a va_list. AsciiPrint() too is defined in EDK2's PrintLib.h, though our implementation
just invokes the Unicode version and then converts the buffer to ASCII.
The __builtin_va_###() intrinsics apply only to GCC-like compilers and
MSVC's <stdarg.h> works just fine with gnu-efi.
Without this patch, one has to define GNU_EFI_USE_EXTERNAL_STDARG to
make gnu-efi work with a Microsoft toolchain, which is annoying...
As EFI_SHELL_PARAMETERS_PROTOCOL is also defined in UEFI Shell Spec,
put it together with EFI_SHELL_PROTOCOL.
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@intel.com>
