* The last part of this: I hope :)
* ISO C permits overwriting of Src even if it marks Src as CONST
* UEFI marks Src as NON CONST, so forward calls via this function
* Allows us to keep in-line with shim without causing Werror havoc with other downstreams
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
This is similar to using automake's silent rules and, just as with automake,
can be disabled by invoking 'make V=1'.
Signed-off-by: Pete Batard <pete@akeo.ie>
On ARM32 only, it appears that whenever Visual Studio inlines the FloatToString()
call (which it does for Release builds), the resulting executable produces an
"Undefined OpCode Exception" on Print() invocation, regardless of whether there
is an actual float to string conversion occurring there.
To work around this, add an explicit clause to prevent inlining, and do so on all
platform just in case.
Signed-off-by: Pete Batard <pete@akeo.ie>
Per binutils/docs/as/Section.html, COFF assembly, which is what MinGW uses, does not
allow @type/%type, which is an ELF-only thing. As a result, trying to assemble the
recently modified ctor.S with MinGW produces the error:
Error: junk at end of line, first unrecognized character is `,'
Fix this by making sure ELF-specifics are only added within ELF-guarded sections.
Note: This fixes the now deleted https://sourceforge.net/p/gnu-efi/bugs/38/
Signed-off-by: Pete Batard <pete@akeo.ie>
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.
This makes our "make clean" commands show what they've /removed/, rather
than what the shell code that will be run is.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
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>
* Make entry.c work correctly in reverse order
* Remove incorrectly sized (on non-32bit) NULLs from ctors.S
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
Right now whenever we have shell commands with loops, errors in the
middle are accidentally ignored, and make continues to process commands.
This adds 'set -e' to all of those, so they'll propagate back up.
Signed-off-by: Peter Jones <pjones@redhat.com>
This makes setup and teardown functions defined with
__attribute__((__constructor__) and __attribute__((__destructor__)) work
in normal circumstances in EFI binaries.
A couple of notes:
- it implements both the old-style .ctors/.dtors methods and the newer
style .init_array/.fini_array ELF constructor and destructor arrays,
processed in the order:
.init_array[]
.ctors[]
efi_main()
.dtors[]
.fini_array[]
- Destructors will only be called if efi_main() exits using "return";
any call to Exit() will still longjmp() past them.
- InitializeLib() has already been called before constructors run, so
they don't need to call it (and neither does anything else.) For
compatibility, it has been altered so calling it more than once is
safe.
- No attempt is made to handle any constructor or destructor with a
prototype other than "void func(void);", but note that InitializeLib
has been called, so LibImageHandle, ST, BS, and RT are set.
- The init_array/ctor/dtor/fini_array lists aren't the using the GNU
"CONSTRUCTOR" output section command, so they don't start with a size.
- The lists are individually sorted during the link stage via
SORT_BY_NAME() in the linker script.
- The default (empty) init_array/ctor/dtor/fini_array lists are padded
out to 8-byte alignment with ".p2align 3, 0", and each list always has
at least one ".long 0" at the end of it (even if it's completely
empty). As a result, they can have NULLs that need to be skipped.
The sections they're in are mergeable, so the NULLs don't have to be
exclusively at the end.
- The ia64 and mips64el arches have not been tested.
Signed-off-by: Peter Jones <pjones@redhat.com>
This is ascii order but with upper and lower case letters mixed, so
things like 'X' and 'x' that use fallthrough still stay together.
Signed-off-by: Peter Jones <pjones@redhat.com>
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>
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
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>
