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> |
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/ |
5b74db0e | 15-Mar-2019 |
Nigel Croxon <ncroxon@redhat.com> |
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> |
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 ...
|
9ce3546d | 23-Sep-2015 |
Nigel Croxon <nigel.croxon@hpe.com> |
From: Pete Batard <pete@akeo.ie> Subject: [PATCH] Fix MSVC breakage due to GNU align extensions in setjmp
* __attribute__((__aligned__(x))), which is used in setjmp, is GNU only => use a macro inste
From: Pete Batard <pete@akeo.ie> Subject: [PATCH] Fix MSVC breakage due to GNU align extensions in setjmp
* __attribute__((__aligned__(x))), which is used in setjmp, is GNU only => use a macro instead
Signed-off-by: Pete Batard <pete@akeo.ie> Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
show more ...
|
dae0b4b0 | 14-May-2015 |
Nigel Croxon <nigel.croxon@hp.com> |
Turns out we actually need setjmp in one of gnu-efi's prominent users, and it seems to make more sense to put it here than in the application.
All of these are derived from the Tiano code, but I re-
Turns out we actually need setjmp in one of gnu-efi's prominent users, and it seems to make more sense to put it here than in the application.
All of these are derived from the Tiano code, but I re-wrote the x86_64 one because we use the ELF psABI calling conventions instead of the MS ABI calling conventions. Which is to say you probably shouldn't setjmp()/longjmp() between functions with EFIAPI (aka __attribute__((ms_abi))) and those without.
Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Nigel Croxon <nigel.croxon@hp.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> |