Commit Graph

201 Commits

Author SHA1 Message Date
Nigel Croxon
9b14e7dab0 Bump revision to VERSION = 3.0.10 2019-10-03 12:05:00 -04:00
Nigel Croxon
3e4d5c7990 Merge /u/lslrt/gnu-efi/ branch exclude_efisetjmp into master
https://sourceforge.net/p/gnu-efi/code/merge-requests/8/
2019-05-16 20:31:59 +00:00
leo
486ba3c3bd Do not include efisetjmp.h on efi.h
People than really want to use efisetjmp implementation can include
the header on their own.

Signed-off-by: leo <leo.sartre@geebol.fr>
2019-05-15 05:32:24 +02:00
leo
238358c6df efiapi.h: fix EventGroup parameter of EFI_CREATE_EVENT_EX prototype
From UEFI specifications, this parameter is a pointer, see
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
page 148 for reference.

Signed-off-by: leo <leo.sartre@geebol.fr>
2019-05-14 07:44:28 +02:00
Nigel Croxon
230c36c6aa gnuefi/Makefile uses a strange rule to create libgnuefi.a, which only works
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>
2019-04-02 09:47:24 -04:00
Nigel Croxon
7604ff2629 Merge /u/esben/gnu-efi/ branch intptr-t-fix into master
https://sourceforge.net/p/gnu-efi/code/merge-requests/5/
2019-03-22 18:02:34 +00:00
Nigel Croxon
99c1436dc9 Merge /u/ffontaine35/gnu-efi/ branch master into master
https://sourceforge.net/p/gnu-efi/code/merge-requests/3/
2019-03-22 18:01:07 +00:00
Nigel Croxon
de4e5e4e3b Make.rules incomplete/wrong; make -r failure
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>
2019-03-15 09:48:10 -04:00
Nigel Croxon
5b74db0e15 Redefine jmp_buf to comply with C calling convention.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
2019-03-15 09:32:06 -04:00
Esben Haabendal
1a53d8f88a Fix for problem with undeclared intptr_t type
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>
2019-03-15 12:09:50 +01:00
Fabrice Fontaine
6335e5c697 efilink: fix build with gcc 4.8
intptr_t is undefined without an include on stdint.h

Fixes:
 - http://autobuild.buildroot.org/results/a0ca37b5ed27af445344e3ac49dc87bb17512c50

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
2019-01-18 22:12:38 +01:00
Nigel Croxon
d34132e62f * Fixed typeo lib/error.c EFI_WARN_UNKNOWN_GLYPH definition.
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>
2019-01-09 07:03:46 -05:00
Nigel Croxon
5d0d538c25 Fix typeo in efierr.h EFI_WARN_UNKNOWN_GLYPH definition.
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
Signed-off-by: manison <manison@users.sf.net>
2019-01-08 11:19:25 -05:00
Gary Lin
5bb5032fda Set '\0' properly in StrnCpy()
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>
2018-10-12 08:17:20 -04:00
Nigel Croxon
183ec634ee Bump revision to VERSION = 3.0.9 2018-10-11 08:46:29 -04:00
Gary Lin
ba250504b9 Implement StrnCat() without StrnCpy()
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>
2018-10-11 08:35:12 -04:00
Gary Lin
6058ffcd54 Set '\0' properly in StpnCpy()
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>
2018-10-11 08:35:06 -04:00
Pete Batard
85f1c797f6 Fix conversion from 'UINTN' to 'UINT8' warnings
* MSVC generates two of the following in rtstr.c:
  warning C4244: 'function': conversion from 'UINTN' to 'UINT8', possible loss of data
2018-05-01 08:00:48 -04:00
Nigel Croxon
fc5af9e47f Bump revision from VERSION = 3.0.7 to VERSION = 3.0.8
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
2018-03-14 14:54:51 -04:00
Peter Jones
b030bfce35 Add debug helper applications
Add debug helper applications.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
2018-03-14 14:50:23 -04:00
Peter Jones
656e495d51 Call ar in deterministic mode.
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>
2018-03-14 14:50:23 -04:00
Peter Jones
be57aadba6 Nerf -Werror=pragma away
Nerf -Werror=-pragma away

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
2018-03-14 14:50:23 -04:00
Peter Jones
5ec879ace7 apps: Add bltgrid and lfbgrid, and add error checks to modelist
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>
2018-03-14 14:50:23 -04:00
Peter Jones
2c624c22fe Make ARCH overrideable on the command line
Make ARCH overrideable on the command line.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
2018-03-14 14:50:23 -04:00
Peter Jones
28793041d7 Add %D to print device paths
Add %D to print device paths.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
2018-03-14 14:50:23 -04:00
Peter Jones
9485c65f6d gnu-efi: add some more common string functions.
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>
2018-03-14 14:50:23 -04:00
Peter Jones
5abc3858a2 Fix another place clang complains about
Fix another place clang complains about.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
2018-03-14 14:50:23 -04:00
Peter Jones
f0bf464a37 make clang not complain about -fno-merge-all-constants
Make clang not complain about -fno-merge-all-constants

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
2018-03-14 14:50:23 -04:00
Peter Jones
28b487d1ae Fix typedef of EFI_PXE_BASE_CODE
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>
2018-03-14 14:50:23 -04:00
Peter Jones
25cebcee2a Fix a sign error in the debughook example app
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>
2018-03-14 14:50:23 -04:00
Peter Jones
e861bb3861 Work around -Werror=maybe-uninitialized not being very bright.
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>
2018-03-14 14:50:23 -04:00
Peter Jones
5fa13d4609 Fix arm build paths in the makefile
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>
2018-03-14 14:50:22 -04:00
Peter Jones
a46a62b12b Fix some types gcc doesn't like
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>
2018-03-14 14:50:22 -04:00
Nigel Croxon
3b523e30f3 Merge /u/trofi/gnu-efi/ branch fix-64-build into master
https://sourceforge.net/p/gnu-efi/code/merge-requests/2/
2018-01-29 18:18:20 +00:00
Sergei Trofimovich
0e6995a96b gnu-efi: fix lib/ia64/setjmp.S IA-64 build failure
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>
2018-01-28 16:44:21 +00:00
Sergei Trofimovich
2cc0b085fb gnuefi: preserve .gnu.hash sections (unbreaks elilo on IA-64)
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>
2018-01-27 20:29:05 +00:00
Nigel Croxon
d039cd620b Currently we have DivU64x32 on ia32, but it tries to call
__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>
2018-01-10 10:28:36 -05:00
Nigel Croxon
f99001cd7d Bump revision from VERSION = 3.0.6 to VERSION = 3.0.7
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
2017-11-06 09:44:21 -05:00
Nigel Croxon
b1d426ce67 Move memcpy/memset definition to global init.c
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>
2017-11-06 09:38:38 -05:00
Nigel Croxon
787b53a66c Add EFI_DRIVER_ENTRY_POINT support for MSVC/ARM64
Similar to what we do for other MSVC architectures.

Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
2017-11-06 09:34:14 -05:00
Nigel Croxon
39ce220cb6 Make sure stdint.h is always used with MSVC on ARM/ARM64, since all
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>
2017-11-06 09:26:05 -05:00
Nigel Croxon
15bcddc996 Stripped diff for makefile
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>
2017-11-06 09:06:31 -05:00
Nigel Croxon
08a46615c7 Use ARFLAGS when invoking ar.
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>
2017-08-07 13:32:54 -04:00
Nigel Croxon
99d94682de [PATCH] Disable AVX instruction set on IA32 and x86_64 platforms
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>
2017-07-13 08:43:16 -04:00
Nigel Croxon
af5d1494a9 -VERSION = 3.0.5
+VERSION = 3.0.6

Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
2017-06-20 10:12:22 -04:00
Nigel Croxon
bf07e81417 Declare EFI_PXE_BASE_CODE correctly
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>
2017-06-14 08:05:45 -04:00
Nigel Croxon
61859152d8 This commit inserts the libefi.a objects in a stable order.
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>
2017-06-01 07:47:37 -04:00
Nigel Croxon
8d8a3b5dff Add the fallthrough attribute to notify gcc7 that it's on purpose.
Signed-off-by: Gary Lin <glin@suse.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
2017-05-31 06:53:49 -04:00
Nigel Croxon
08b72e8d99 This typedef is already defined with the structure and can
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>
2017-05-30 19:36:55 -04:00
Nigel Croxon
72a19c3a00 On x86_64, newish gcc will use relocation types R_X86_64_GOTPCREL,
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>
2017-04-07 13:16:58 -04:00