rhboot / fwupdate

System firmware update support for UEFI machines
99 stars 47 forks source link

efi: Fix build on armhf #121

Closed superm1 closed 6 years ago

superm1 commented 6 years ago

Debian & Ubuntu are FTBFS currently for armhf with this error:

$ arm-linux-gnueabihf-gcc -nostdlib -Wl,--warn-common -Wl,--no-undefined -Wl,--fatal-warnings -Wl,-shared -Wl,-Bsymbolic -L/usr/lib -L/usr/lib -Wl,--build-id=sha1 -Wl,--hash-style=sysv /usr/lib/crt0-efi-arm.o -Wl,--defsym=EFI_SUBSYSTEM=0xa -o fakeesrt2.so fakeesrt2.o -lefi -lgnuefi \
    /usr/lib/gcc/arm-linux-gnueabihf/8/libgcc.a " " \
    -T elf_arm_efi.lds
arm-linux-gnueabihf-gcc: error:  : No such file or directory

This is caused by a missing $ in the "sed" command for switching in libgcc_eh.

However there is also a secondary problem in that the build is run with -fexceptions which doesn't work for armhf.

It fails with this:

$ arm-linux-gnueabihf-gcc -nostdlib -Wl,--warn-common -Wl,--no-undefined -Wl,--fatal-warnings -Wl,-shared -Wl,-Bsymbolic -L/usr/lib -L/usr/lib -Wl,--build-id=sha1 -Wl,--hash-style=sysv /usr/lib/crt0-efi-arm.o -Wl,--defsym=EFI_SUBSYSTEM=0xa -o fakeesrt2.so fakeesrt2.o -lefi -lgnuefi \
    /usr/lib/gcc-cross/arm-linux-gnueabihf/7/libgcc_eh.a \
    -T elf_arm_efi.lds
/usr/bin/arm-linux-gnueabihf-ld: warning: /usr/lib/gcc-cross/arm-linux-gnueabihf/7/libgcc_eh.a(unwind-arm.o) uses 4-byte wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t values across objects may fail
/usr/bin/arm-linux-gnueabihf-ld: warning: /usr/lib/gcc-cross/arm-linux-gnueabihf/7/libgcc_eh.a(pr-support.o) uses 4-byte wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t values across objects may fail
/usr/lib/gcc-cross/arm-linux-gnueabihf/7/libgcc_eh.a(unwind-arm.o): In function `get_eit_entry':
(.text+0x154): undefined reference to `__exidx_end'
(.text+0x158): undefined reference to `__exidx_start'
/usr/lib/gcc-cross/arm-linux-gnueabihf/7/libgcc_eh.a(unwind-arm.o): In function `unwind_phase2':
(.text+0x1f0): undefined reference to `abort'
/usr/lib/gcc-cross/arm-linux-gnueabihf/7/libgcc_eh.a(unwind-arm.o): In function `__gnu_Unwind_Resume':
(.text+0x394): undefined reference to `abort'
(.text+0x3ac): undefined reference to `abort'
/usr/lib/gcc-cross/arm-linux-gnueabihf/7/libgcc_eh.a(pr-support.o): In function `_Unwind_GetDataRelBase':
(.text+0x382): undefined reference to `abort'
collect2: error: ld returned 1 exit status
Makefile:114: recipe for target 'fakeesrt2.so' failed
make: *** [fakeesrt2.so] Error 1
rm fakeesrt2.o
hughsie commented 6 years ago

Looks good, but I wonder why we needed fexceptions on the first place. Maybe we want fnoexceptions or whatever the argument is called?

superm1 commented 6 years ago

Looks like it came from this commit along with a bunch of other compiler flags.

commit 4cfd9948f4c3cb3b764f359ae43ed2a26732ee87
Author: Peter Jones <pjones@redhat.com>
Date:   Fri May 19 16:52:36 2017 -0400

    Use -g3 -Og, stack protector, and fortify source by default

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

These are the same CFLAGs applied to the linux directory Makefile too. My guess is this just wasn't obviously hit previously because all the packaged builds override CFLAGS to put their own hardening in place.

I don't believe compiling in exception handling to the EFI application is likely to work anyway on any architecture, right?

superm1 commented 6 years ago

Reading through https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

I don't believe adding -fno-exceptions is going to be useful with C code. Just drop the compiler flag and it should be sufficient.

Enable exception handling. Generates extra code needed to propagate exceptions. For some targets, this implies GCC generates frame unwind information for all functions, which can produce significant data size overhead, although it does not affect execution. If you do not specify this option, GCC enables it by default for languages like C++ that normally require exception handling, and disables it for languages like C that do not normally require it. However, you may need to enable this option when compiling C code that needs to interoperate properly with exception handlers written in C++. You may also wish to disable this option if you are compiling older C++ programs that don’t use exception handling.

hughsie commented 6 years ago

Thanks for the detective work!