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...
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>
* __STDC_VERSION__ is undefined when headers are called from C++
code resulting in not using stdint.h and efibind.h
"making a guess" on what they are. extern "C" will not define
__STDC_VERSION__.
* Always leverage stdint.h on C++.
* Honestly, gnu-efi should always use stdint.h, or find a better
way to detect it. (or platforms without it need to catch up to 2007)
Breaks gcc builds with '-nostdinc' flag.
The fix in 1a53d8f88a
(Fix for problem with undeclared intptr_t type), which is also merged
fixes the same problem, without causing breakage.
This reverts commit 6335e5c697.
because of a "make" builtin rule. This breaks make -r, and it is an
inefficient way to build, at least for multiple files.
I have made a git tree which includes a patch for this problem,
and also forces -r by adding it to MAKEFLAGS:
git://git.zytor.com/users/hpa/gnu-efi.git make-r-fixes
Signed-off-by: H. Peter Anvin <hpa@users.sourceforge.net>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
Make.rules is not complete; in particular it lacks a %.o: %.S rule.
This happens to work due to the builtin make rule to that effect. but
building with make -r, or building as a sub-make of an environment that
uses make -r (or MAKEFLAGS += -r) causes it to break.
In general, make -r is strongly preferred, and Make.rules seems to have
been created explicitly to support this.
To further complicate things, the rule %.S: %.c causes a completely
incomprehensible error message. This rule is wrong, it should be %.s:
%.c not %.S: %.c.
Finally, the rule %.E: %.c is normally %.i: %.c; .i is the normal
extension for preprocessed C source. The equivalent rule for assembly is
%.s: %.S.
Signed-off-by: H. Peter Anvin <hpa@users.sf.net>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
When building gnu-efi with old compilers with pre C90 compilers:
In file included from gnu-efi-3.0.9/lib/../inc/efilib.h:25:0,
from gnu-efi-3.0.9/lib/lib.h:24,
from gnu-efi-3.0.9/lib/dpath.c:25:
gnu-efi-3.0.9/lib/dpath.c: In function 'FileDevicePath':
gnu-efi-3.0.9/lib/../inc/efilink.h:145:47: error: 'intptr_t' undeclared (first use in this function)
#define EFI_FIELD_OFFSET(TYPE,Field) ((UINTN)(intptr_t)(&(((TYPE *) 0)->Field)))
Problem introduced with commit a46a62b12b
(Fix some types gcc doesn't like).
Avoid this by adding intptr_t (and uintptr_t) typedefs for builds that does
not include stdint.h.
Signed-off-by: Esben Haabendal <esben@esben1.localdomain>
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>
We need the x86_64 and i686 builds of .a's to be the same, and that
means we need to not have timestamps. Also force the timestamps on disk
just in case that doesn't work, because RHEL's ar /silently ignores -D/.
v2: use "ar rvD" not "ar rv -D".
It's a wonder anybody ever gets these command line options right, if
"ar rv -D libfoo.a foo.o" doesn't use deterministic mode (or
complain), but "ar rvD libfoo.a foo.o" does.
v3: Add a bunch of junk to try to set timestamps to 0 manually
For some reason I'm still getting timestamps in the .a even though ar seems to
be invoked correctly. When I do "mock -r rhel-7-build --shell" and run make
manually, they're fine. Very strange.
v4: go back to v2, the problem isn't in the make process.
"ar rDv" works just fine, but /usr/lib/rpm/redhat/brp-strip-static-archive is
calling "%{__strip} -g $for_each.a", and it's rewriting our binary from
ts/uid/gid of 0/0/0 to $epoch/$UID/$GID. Awesomely /usr/bin/strip it seems to
have 3 modes of operation:
-U: the default, which adds $epoch/$UID/$GID to your binary archive
instead of just removing stuff. Clearly the Principle of Least
Surprise is strong here.
-p: preserve the timestamp from the original .a, but add UID and GID,
because this is 1980 and people use ar(1) for archiving stuff they
might want that out of.
-D: Condescend at you in a command line error and explain that -D both
is and is not a valid option:
/usr/bin/strip: invalid option -- 'D'
Usage: /usr/bin/strip <option(s)> in-file(s)
Removes symbols and sections from files
The options are:
...
-D --enable-deterministic-archives
Produce deterministic output when stripping archives
So I agree that it's invalid, but I think we may be pronouncing that
second vowel differently. They say in-VAL-id, I say IN-vuh-lid.
Nobody should ever have to run "strace -ttt -v -f -o make.strace make all",
just to discover the problem isn't even in there.
Related: rhbz#1310782
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
This adds bltgrid and lfbgrid, which draw checkerboards using GOP's
Blt() and linear framebuffer, respectively, and adds some error checks
to modelist.efi.
Signed-off-by: Peter Jones <pjones@redhat.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>
Commit 751cbce3 fixed up a bunch of types to better match the edk2
definitions and the names in the UEFI Spec, but while doing so
inadvertantly defined things thusly:
INTERFACE_DECL(_EFI_PXE_BASE_CODE_PROTOCOL);
...
typedef struct _EFI_PXE_BASE_CODE_PROTOCOL {
...
} EFI_PXE_BASE_CODE_PROTOCOL;
...
typedef struct _EFI_PXE_BASE_CODE_PROTOCOL _EFI_PXE_BASE_CODE;
typedef struct EFI_PXE_BASE_CODE_PROTOCOL EFI_PXE_BASE_CODE;
Because EFI_BASE_CODE_PROTOCOL is declared with a typedef, and is
therefore in the type namespace rather than the struct namespace, this
results in EFI_PXE_BASE_CODE being a forward declaration of an
incomplete type. The net result is that code which dereferences any
field in the struct, even with the correct names, will not correctly
build.
This patch changes both _EFI_PXE_BASE_CODE and EFI_PXE_BASE_CODE
typedefs to inherit from struct _EFI_PXE_BASE_CODE_PROTOCOL.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
On ISO C90 on i386 4294967294 is a signed integer, and so x can't be
greater (or equal) to that. Make it an unsigned and choose a better type
for the variable.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
The compiler doesn't believe the loop always executes at least once,
even though the data in the first array entry doesn't satisfy the exit
condition. So just initialize the thing to shut it up.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
Previous work was apparently done with arm-linux-gnueabi-gcc as a
cross-builder, but our armv7 builders have native gcc with the target as
armv7hl-linux-gnueabi, so we need to munge the arch there to get our arm
path.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
Most of these come from building on i386 with -Wextra, but they're still
incorrect everywhere else; they just happen to have identical typedefs
at other places, so the compiler doesn't care.
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>
Gentoo has slightly modified linker defaults: --hash-style=gnu
This means all ELF files in system have '.gnu.hash' section
but no '.hash' section.
gnuefi's ldscript did not account for it and as a result
one symbol 'ImageBase' did not resolve locally for elilo.so
and caused 'elilo' to fail to load by ia64 EFI:
Loading.: Gentoo (try new elilo)
ImageAddress: pointer is outside of image
ImageAddress: pointer is outside of image
Those two relocations come from crt0-efi-ia64.S PE32 entry point
fdescr:
```
#define IMAGE_REL_BASED_DIR64<->10
.section .reloc, "a"
data4 _start_plabel // Page RVA
data4 12 // Block Size (2*4+2*2)
data2 (IMAGE_REL_BASED_DIR64<<12) + 0 // reloc for plabel's entry point
data2 (IMAGE_REL_BASED_DIR64<<12) + 8 // reloc for plabel's global pointer
```
These refer ImageBase.
The change adds '.gnu.hash' collection (follows existing '.hash'
collection).
Tested on IA-64 by successfully booting elilo-3.16.
Bug: https://bugs.gentoo.org/575300
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>
