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>
Tested:
make all apps + tests apps/ on x86_64
make CC=clang all apps + tests apps/ on x86_64
Signed-off-by: David Decotigny <ddecotig@gmail.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
also remove what looks like garbage inside an #if 0 block.
Signed-off-by: David Decotigny <ddecotig@gmail.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>
Patch to allow gcc to emit warnings for unsafe usage of setjmp/long
Signed-off-by: David Decotigny <gdaviddecotigny@users.sf.net>
Signed-off-by: Nigel Croxon <noxorc@mac.com>
Attaching a patch to fix apps/drv0.efi and apps/drv0_use.efi,
which are both currently not working.
Signed-off-by: David Decotigny <gdaviddecotigny@users.sf.net>
Signed-off-by: Nigel Croxon <noxorc@mac.com>
Calling the various Print functions picked up some warnings in my
project (using GCC 4.8 and 4.9 at the moment):
warning: passing argument 1 of Print discards const qualifier from
pointer target type [enabled by default]
Signed-off-by: Nigel Croxon <noxorc@mac.com>
Signed-off-by: Justinian <justinian@users.sf.net>
GNU ar currently produces the following string of warnings:
Warning: Archive 'libefi.a' seems to have been created in
deterministic mode.
'<file>.o' will always be updated. Please consider passing
the U flag to ar to avoid the problem. This patch fixes the issue.
Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <noxorc@users.sf.net>
aarch64-linux-gnu-gcc on Debian/Sid fails lib compilation with:
lib/aarch64/initplat.c:44:35: error: initialization discards
‘const’ qualifier from pointer target type
[-Werror=discarded-qualifiers]. This patch fixes it.
Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <noxorc@users.sf.net>
PCI Root Bridge I/O protocol is used by PCI Bus Driver to perform
PCI Memory, PCI I/O, and PCI Configuration cycles on a
PCI Root Bridge. It also provides services to perform different
types of bus mastering DMA.
V2 - Scratch that - there already exists an efipciio.h with most
of these definitions. Let me remove this patch and propose a new
one that will amend what's already there.
OK, here's a better version that adds the required definition in
efipciio.h. Note that EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL and
EFI_PCI_IO_PROTOCOL are two different protocols.
V3 - Pete, There are now two defines of EFI_PCI_ADDRESS.
Please repost with your define removed.
Nigel, Sorry about that. Here's v3.
Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
This patch adds a few more items to facilitate porting
from EDK to gnu-efi.
It also adds updated PE machine types and fixes a discrepancy
for EVT_EFI_SIGNAL_MAX.
Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
This patch introduces the use of the EDK2 names for the global GUID
variables, to allow for easier code conversion between EDK2 and
gnu-efi. All the existing GUID global variables have also been
aliased for backwards compatibility.
The patch also completes some of the earlier work with regards to
protocol struct definitions to also match the EDK2, with the
following caveat:
Because some of gnu-efi GUID macro definitions were declared with
the name that the EDK2 uses for the protocol struct itself, we have
to immediately deprecate the following GUID data aliases:
EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL
EFI_SIMPLE_NETWORK_PROTOCOL
EFI_PCI_IO_PROTOCOL
EFI_PXE_BASE_CODE_CALLBACK_PROTOCOL
This means that existing code using one of the above will break
on compilation. To mitigate this, explicit warnings have been
placed at the location where a developer will look for breakage,
detailing how they should amend their code.
The KnownGuids short labels in guid.c were also updated/amended
in a manner that should be a bit more consistent (though I have
no idea what the EDK2 does here, since I haven't looked at the
actual EDK2 source).
Finally, besides clean up (typo, whitespaces, duplicate removal),
we introduce the _GNU_EFI macro, in efi.h, to allow for conditional
selection of specific gnu-efi API calls, in code that may be
compiled with either EDK2 or gnu-efi.
Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
and completes the renaming of structs, defines, and typedefs to match
the naming convention from the latest UEFI specifications.
This should make it easier for people to switch between EDK2 and
gnu-efi compilation.
The original names are #defined or typedef'd to the new names for
backwards compatibility. Also some whitespace cleanup was applied.
Note 1: From what I could see of the EDK API documentation,
structs are being aliased to their old names using typedef rather
than #define, so that's what I used. I altered some of the #define
from 8118d0 accordingly
Note 2: I also think it might be more helpful for users to keep
the backwards compatibility defs close to their declaration
(e.g. old GUID def right after current GUID declaration), rather
than in a separate section as was done in 8118d0, so that's what
I did in this patch.
Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
64 bit entry point structure has a different GUID
from the existing 32 bit version.
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
compiled with MSVC: lib\print.c(1345): warning C4244:
'initializing': conversion from 'double' to 'float',
possible loss of data
Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
EFI_EDID_ACTIVE_PROTOCOL
EFI_EDID_DISCOVERED_PROTOCOL
EFI_EDID_OVERRIDE_PROTOCOL
It also adds the matching global variables to libefi.
Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
This patch corrects the printing of leading fractional
part 0s in Print("%f").
Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
point and as far as I can tell it agrees with the UEFI spec.
The attached patch removes -mno-mmx and -mno-sse for x86_64 and adds
a new Print target, "%f", to print float and double types.
It seems to compile for ia32, although I'm not sure why - shouldn't
it be throwing errors because the new function FloatToStr() in print.c
accepts a float, yet I left -no-sse for ARCH=ia32? A better solution
might be to add -msoft-float for targets where the floating point
calling convention doesn't match the UEFI spec. As I'm not familiar
with UEFI on ia32, I didn't make any changes to it.
Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
This patch renames a number of structs, defines, and typedefs to match
the naming convention in the UEFI specification. For example, it renames
DRIVER_BINDING_PROTOCOL (preprocessor GUID define) to
EFI_DRIVER_BINDING_PROTOCOL_GUID, and renames EFI_DRIVER_BINDING (protocol
interface) to EFI_DRIVER_BINDING_PROTOCOL.
The original names are all #defined to the new names for backwards
compatibility, so nothing should be broken.
Included in this patch are renames for all the types/defines for the
following protocols:
EFI_DRIVER_BINDING_PROTOCOL
EFI_COMPONENT_NAME_PROTOCOL
EFI_COMPONENT_NAME2_PROTOCOL
EFI_LOADED_IMAGE_PROTOCOL
If you accept this patch I'll work on adjusting all the other protocols
to match the spec as well, as time allows. Moving to the spec's naming
convention makes the code clearer and improves portability with EDK2.
Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
EFI_GUID instances) for EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL,
EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL, and
EFI_BUS_SPECIFIC_DRIVER_OVERRIDE_PROTOCOL, used in the driver
binding search procedure to select which driver to connect when
multiple drivers' Supported() functions indicate support for
the same controller.
Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
implicit calls to _umoddi3 and _udivdi3, which are unavailable when
compiling without the standard libraries (-nostdlib).
This patch addresses this by providing an inline assembly definition
that is an exact conversion of the existing MS one, but for GCC's
AT&T syntax.
Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
the MSVC ARM linker, to specify the entry point, as is already the case
for ia32 and x86_64.
Required to enable the compilation of ARM drivers with MSVC, without
having to manually specify the entry point.
Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
implicit call to memcpy(), which can result in an undefined reference.
Use CopyMem() to duplicate struct data instead.
NB: This patch also removes trailing whitespaces in event.c
Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
Windows libraries, the MSVC compiler will throw the error:
gnu-efi.lib(print.obj) : error LNK2019: unresolved external symbol __allmul referenced in function _ValueToHex
Adding an explicit cast on the array index, to ensure that is not larger
than 32 bits, appears to fix the problem.
NB: This patch also removes trailing whitespaces, but the only real change
is on line 1253.
Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
result, which breaks gnu-efi compilation due to -Werror:
gnu-efi/lib/boxdraw.c:1:0: error: -fpic ignored for target
(all code is position independent) [-Werror]
This patch ensures that -fpic is disabled when MinGW is used.
Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
that MSVC compilers will complain about (such as Visual Studio
2015 with ARM target).
Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
x86_32 and x86_64, due to the use of ELF specific assembler
extensions (.type setjmp, @function is not comptaible with PE-COFF).
This patch addresses that, by making sure that we use the equivalent
.type definition for MinGW. Note that I only addressed x86_32 and
x86_64 as I'm not aware of MinGW developments for any other archs.
Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
