Closed superm1 closed 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?
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?
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.
Thanks for the detective work!
Debian & Ubuntu are FTBFS currently for armhf with this error:
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: