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>
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>
This patch allows one to run make outside the source tree
with make -f <makefile>.
Signed-off-by: wolfra <wolfra@users.sf.net>
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>
If gnu-efi is compiled with "-march=native" on a host that supports AVX, both
gcc and clang will use AVX instructions freely which is currently not supported
and will result in a non-functional gnu-efi build (e.g. black screen, hangs).
For now, disable AVX on IA32 and x86_64 by checking first if the compiler does
actually support the appropriate flag (-mno-avx) and use it if possible.
Credit for the compiler command line to check if a flag is supported goes to
Gentoo's awesome flag-o-matic eclass, where it is taken from. Thanks.
Signed-off-by: Matthias Dahl <matthias.dahl@binary-island.eu>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
EFI_PXE_BASE_CODE was redefined in the early commit(*) to match the
definition in EDK2. However, EFI_PXE_BASE_CODE wasn't declared
correctly. Since EFI_PXE_BASE_CODE_PROTOCOL is already an alias of
"struct _EFI_PXE_BASE_CODE_PROTOCOL", the additional struct in front of
EFI_PXE_BASE_CODE_PROTOCOL actually confused the compiler and caused
build fail. Remove the redundant struct to avoid confusion.
*751cbce3f640c7 Update global protocol GUIDs definitions to match EDK2
Signed-off-by: Gary Lin <glin@suse.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>
generate an error ("typedef redefinition is only available
in C11") with Clang.
Signed-off-by: Pete Batard <pete@akeo.ie>
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>
