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

Bump revision from VERSION = 3.0.7 to VERSION = 3.0.8

Signed-off-by: Nigel Croxon <ncroxon@redhat.com>

Add debug helper applications

Add debug helper applications.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>

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

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>

show more ...

Nerf -Werror=pragma away

Nerf -Werror=-pragma away

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>

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 ch

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>

show more ...

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>

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>

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

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>

show more ...

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>

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@red

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>

show more ...

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

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>

show more ...

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 v

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>

show more ...

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

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>

show more ...

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,

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>

show more ...

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 th

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>

show more ...

Merge /u/trofi/gnu-efi/ branch fix-64-build into master

https://sourceforge.net/p/gnu-efi/code/merge-requests/2/

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.nt

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>

show more ...

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

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>

show more ...

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 <

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>

show more ...

Bump revision from VERSION = 3.0.6 to VERSION = 3.0.7

Signed-off-by: Nigel Croxon <ncroxon@redhat.com>

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/mem

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>

show more ...

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>

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,

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>

show more ...

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

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>

show more ...