* Add efi_machine_type_name and gnu_efi_arch from fwupd-efi
* Add gnu_efi_default_is_objcopy so downstreams know if the crt0 goes objcopy
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
To builds the apps with MinGW, the CRT0 library must be ignored because
it is ELF specific and we don't need to go through ELF relocations.
We also apply the GNU_EFI_USE_MS_ABI (since we have it), remove the -z
flags, that are invalid in MinGW, and clean up the apps Makefile.
Note that setjump and debughook are excluded from MinGW builds as they
use constructs that are not available there.
Signed-off-by: Pete Batard <pete@akeo.ie>
On ARM32 only, it appears that whenever Visual Studio inlines the FloatToString()
call (which it does for Release builds), the resulting executable produces an
"Undefined OpCode Exception" on Print() invocation, regardless of whether there
is an actual float to string conversion occurring there.
To work around this, add an explicit clause to prevent inlining, and do so on all
platform just in case.
Signed-off-by: Pete Batard <pete@akeo.ie>
Guard the macros by the compilers they should explicitly apply to and
add a #error in case the compiler has no alignment directive defined,
as ignoring alignment is likely to produce runtime errors.
Also prefer _MSC_VER to _MSC_EXTENSIONS, as _MSC_EXTENSIONS may not
always be defined by the MSVC compiler.
Signed-off-by: Pete Batard <pete@akeo.ie>
For downright incomprehensible reasons the Ubuntu/MinGW folks have decided that MinGW on
Ubuntu should no longer report the compiler's version as '<major>.<minor>', but instead as
'<major>-win32', which of course breaks any script that attempts to read version numbers.
This results in MinGW compilation of gnu-efi on Ubuntu producing the error:
/bin/sh: 1: [: Illegal number: 10-win32
Fix this by replacing any '-win32' in the -dumpversion report with '.0' so that we get an
approximate version number back again.
Signed-off-by: Pete Batard <pete@akeo.ie>
Per binutils/docs/as/Section.html, COFF assembly, which is what MinGW uses, does not
allow @type/%type, which is an ELF-only thing. As a result, trying to assemble the
recently modified ctor.S with MinGW produces the error:
Error: junk at end of line, first unrecognized character is `,'
Fix this by making sure ELF-specifics are only added within ELF-guarded sections.
Note: This fixes the now deleted https://sourceforge.net/p/gnu-efi/bugs/38/
Signed-off-by: Pete Batard <pete@akeo.ie>
The UEFI shorthands, as used in /efi/boot/boot###.efi, can now be used to specify the arch.
This basically adds 'x64' and 'mips64' as valid arch specifiers.
Signed-off-by: Pete Batard <pete@akeo.ie>
As explained at https://stackoverflow.com/a/49830956/1069307, 'asm' is a GNU
extension that will produce an error when using a non GNU standard like -std=c11.
With recent commit 9b1e06cd0c having fixed our use
of -std=c11, the MIPS build failed with the error above.
With this sorted, we also re-enable the MIPS gcc build in GitHub Actions.
This was hopefully just a typo that has been cargo-culted around the codebase.
It certainly confuses the Red Hat license checker and makes the code copyright
clear.
No point having PT_GNU_RELRO as ELF data won't exist when merging into PE32+ file
Unbreaks lld usage which complains about linker script
Fixesncroxon/gnu-efi#4
This makes our "make clean" commands show what they've /removed/, rather
than what the shell code that will be run is.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
While binutils 2.25 incorrectly changed the page size
to 64K, the second part of that fix prevents the bug
anyways
Signed-off-by: Callum Farmer <gmbr3@opensuse.org>
Binutils 2.41 now supports efi-app-loongarch64, so to use this we must add a
dummy reloc section and remove the PE header definition from crt0 as this will
conflict with the version added by objcopy
Signed-off-by: Xiaotian Wu <wuxiaotian@loongson.cn>
