History log of /DragonStub/inc/arm/efibind.h (Results 1 – 16 of 16)
Revision Date Author Comments
# dcced034 17-Apr-2023 b'Nigel Croxon <allura@localhost>

Merge /u/gmbr3/gnu-efi/ branch CHAR16 into master

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


# 056bdaa5 13-Apr-2023 Callum Farmer <gmbr3@opensuse.org>

Make VOID a typedef

'void' is a type so VOID can be typedef instead of
a '#define' to improve compiler output

Signed-off-by: Callum Farmer <gmbr3@opensuse.org>


# 189200d0 08-Apr-2023 Callum Farmer <gmbr3@opensuse.org>

Make WCHAR and CHAR16 identical

And actually use wchar_t
gnu-efi already uses L string literals which are of type
wchar_t

Signed-off-by: Callum Farmer <gmbr3@opensuse.org>


# 14899d89 27-Aug-2019 Peter Jones <pjones@redhat.com>

Make CHAR8 and similar be defined the same way edk2 does it.

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


# 9e7e6822 17-May-2021 b'Nigel Croxon <allura@localhost>

Merge /u/xypron/gnu-efi/ branch GCC_visibility into master

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


# fa506bd2 28-Jun-2016 Ard Biesheuvel <ard.biesheuvel@linaro.org>

ARM: hide 'hidden' pragma for hosted build

The hidden visibility #pragma in inc/arm/efibind.h was meant to inform
the compiler that symbols with external linkage are never exported from
shared libra

ARM: hide 'hidden' pragma for hosted build

The hidden visibility #pragma in inc/arm/efibind.h was meant to inform
the compiler that symbols with external linkage are never exported from
shared libraries [and thus never preempted] when executing in UEFI context
(since UEFI does not support shared libraries). This allows the compiler to
generate relative symbol references instead of GOT entries, which is much more
efficient since the latter need to be relocated before invoking the entry
point of the UEFI app.

However, as it turns out, this pragma is leaking into other code that does
not run in UEFI context, but simply needs to access data structures that
UEFI defines. So make the pragma dependent on whether we are building with
-ffreestanding, which is only used for bare metal code such as UEFI.

Last-Update: 2018-08-24

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

Elder versions of sbsigntool failed to build on armhf without the patch,
cf. https://launchpad.net/ubuntu/+source/gnu-efi/3.0.8-0ubuntu1~16.04.1
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

show more ...


# 6685cd00 27-Nov-2019 Alexander von Gluck IV <kallisti5@unixzen.com>

efibind: Fix usage of efi headers from C++ code

* __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

efibind: Fix usage of efi headers from C++ code

* __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)

show more ...


# 7604ff26 22-Mar-2019 Nigel Croxon <allura@localhost>

Merge /u/esben/gnu-efi/ branch intptr-t-fix into master

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


# 1a53d8f8 15-Mar-2019 Esben Haabendal <esben@esben1.localdomain>

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 gn

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 a46a62b12b58139c31d4288384808365c4053bf2
(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>

show more ...


# 39ce220c 06-Nov-2017 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 ...


# 574b48d8 30-Mar-2017 Nigel Croxon <ncroxon@redhat.com>

This is mere refactoring of the code and is not linked to any
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

This is mere refactoring of the code and is not linked to any
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>

show more ...


# 6605c16f 07-Apr-2016 Nigel Croxon <nigel.croxon@hpe.com>

This patch simply duplicates the use of /ENTRY option being passed to
the MSVC ARM linker, to specify the entry point, as is already the case
for ia32 and x86_64.

Required to enable the compilation

This patch simply duplicates the use of /ENTRY option being passed to
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>

show more ...


# 58e6955b 28-Mar-2016 Nigel Croxon <nigel.croxon@hpe.com>

The following fixes a couple GCC specifics for the ARM platform,
that MSVC compilers will complain about (such as Visual Studio
2015 with ARM target).

Signed-off-by: Pete Batard <pbatard@users.sf.ne

The following fixes a couple GCC specifics for the ARM platform,
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>

show more ...


# 333bf05d 07-Jan-2016 Nigel Croxon <nigel.croxon@hpe.com>

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH v2] ARM/AARCH64: define C99 types explicitly when building against
older standard

This adds support for the C99 uintXX_t types when b

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH v2] ARM/AARCH64: define C99 types explicitly when building against
older standard

This adds support for the C99 uintXX_t types when building for
older versions of the standard, like the other architectures
already implement.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...


# d119b0d7 23-Dec-2015 Nigel Croxon <nigel.croxon@hpe.com>

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH 2/2] Replace ARM arithmetic support routines
with EDK2 versions.

Replace the incomplete GPL licensed ARM arithmetic support routines

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH 2/2] Replace ARM arithmetic support routines
with EDK2 versions.

Replace the incomplete GPL licensed ARM arithmetic support routines
with the ones from the EDK2 project. These cover long long multiplication
and long long logical shift as well.

Also remove the special case for small dividends in DivU64x32: we can
simply let the compiler handle this, and emit calls to the support
routines where appropriate.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>

show more ...


# 530d68ba 25-Nov-2014 Nigel Croxon <nigel.croxon@hp.com>

The gnu-efi-3.0 toplevel subdirectory is really annoying. Kill it.

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