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>
StrnCpy() doesn't guarantee the dest string will be null-terminated, so
we shouldn't use StrnCpy().
Signed-off-by: Gary Lin <glin@suse.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
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>
This adds bounded string helper functions:
StrnLen()
StrnCpy()
StrnCat()
StpnCpy()
And the unbounded function StpCpy().
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
The build failed as:
lib/ia64/setjmp.S:171: Error: Unknown opcode `ldf.nt1 f26=[r10],8'
lib/ia64/setjmp.S:178: Error: Operand 1 of `ldf.fill.nt1' should be a floating-point register
The change syncs longjmp definition with
edk2/EdkCompatibilityPkg/Foundation/Library/EdkIIGlueLib/Library/BaseLib/Ipf/setjmp.s
pulling in:
- branch in the end of function
- registers used wrong instruction for float restore
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
__umoddi3 and __udivdi3 from libgcc, which we don't have.
This fixes it to use our implementation in that case.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
Following up on previous patch, I think we should move
memcpy/memset definitions to the global init.c, since MSVC does
also inserts calls to memset/memcpy for the x86_32 platform,
even when disabling standard libraries and intrinsics.
All in all, it looks like, for all platforms, we should assume
that a compiler may still insert these calls regardless.
Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
the versions of Visual Studio that support ARM or ARM64 have that
header. Without this, uint64_t would be defined to unsigned long,
which is 32-bits in the Microsoft world.
Also fix aarch64/initplat.c so that memset/memcpy only apply
to gcc. Otherwise MSVC throws an error for __SIZE_TYPE__.
Updating this patch to v2, since it turns out MSVC will also emit
memset and memcpy intrinsics that we can use an implementation for.
This is true for both ARM and ARM64.
To make this work, I'm defining __SIZE_TYPE__ to UINTN if not
already defined.
Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
The use of ARFLAGS makes these flags overridable.
The '-U' option is already added to ARFLAGS in Make.defaults.
Signed-off-by: Janosch Hildebrand <jnosh+git@jnosh.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
When building libefi.a with "make -jN", the object files in libefi.a
will be inserted in a random order. Although it won't hurt the functionality,
it could make the EFI image irreproducible and invalidate the detached
signature after rebuilding libefi.a without any change in the source
code.
Signed-off-by: Gary Lin <glin@suse.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
R_X86_64_GOTPCREL64, R_X86_64_GOTPCRELX, and R_X86_64_REX_GOTPCRELX,
which our _relocate() does not support, for extern declarations visible
to things linking against a DSO. Since we're really just building a .a
here, and *nothing* needs to be exported in the .so sense, we don't need
any of that optimization at all, there's no point in making _relocate()
know how to handle these.
Instead, this patch simply removes the visibility from everything in the
.a, which gets us back to fairly normal relative relocations that wind
up being R_X86_64_RELATIVE in the final binary, which we can handle.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
specific issue.
I think ARM's DivU64x32() would be better located along MultU64x32()
and other calls in ARM's math.c, as having it in a header seems weird,
even with the goal of inlining it. I doubt there's much performance
to be lost from having it non-inline in math.c and it should make the
code breakdown more logical.
Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
