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>
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.
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>
Key input should be consumed to prevent WaitForKey event from being
always triggered and potential buffer overflow.
This fixes issue #26.
Signed-off-by: Kagurazaka Kotori <kagurazakakotori@gmail.com>
On couple of locations in runtime string library (rtstr.c)
there are calls to non-runtime variant of StrLen function.
* Another issue is with formatting 1394 paths.
The F1394_DEVICE_PATH::Guid is formatted as %g, but 1394
GUID is 8 byte integer, not EFI_GUID and therefore should
be formatted as e.g. %016lx (as edk2 does).
* Beyond what's mentioned above, changed the format of the
harddrive path, so it's in line with edk2 format and spec
(2.7 errata A, chapter 10.6.1.6, table 102).
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
Signed-off-by: manison <manison@users.sf.net>
The arguments to SetMem() were wrong. Besides, SetMem() should start at
"Dest + Size" since "Size" will be smaller than "Len" if they are not
equal.
Signed-off-by: Gary Lin <glin@suse.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
