Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

efi: Fix build on armhf #121

Merged
merged 1 commit into from Aug 7, 2018

Conversation

Projects
None yet
2 participants
@superm1
Copy link
Collaborator

commented Aug 5, 2018

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
efi: Fix build on armhf
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

@superm1 superm1 requested review from hughsie and vathpela Aug 5, 2018

@hughsie

This comment has been minimized.

Copy link
Collaborator

commented Aug 5, 2018

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

@superm1

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 7, 2018

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

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 7, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Aug 7, 2018

Thanks for the detective work!

@hughsie hughsie merged commit c2bd33d into master Aug 7, 2018

1 of 2 checks passed

continuous-integration/travis-ci/push The Travis CI build failed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@hughsie hughsie deleted the wip/superm1/fix-armhf branch Aug 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.