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