Was libc built to force exceptions/unwind always on?

[danngreen]

I'm seeing some large (~4kB) amounts of code linked from libc (lib_a-init.o) into my project that seem to do with exceptions, even though my compilation flags should be disabling exceptions and unwind tables.

I'm using xpack-arm-none-eabi-gcc-11.2.1-1.2 for darwin-arm64.
If I use the ARM official release v11.2 (built for darwin-x86_64), then the binary is much smaller, and the 4kB of unwind/exception code is not linked in.

I made a minimal example that illustrates the issue. You can see the whole project here: https://github.com/danngreen/gcc-11-exception-xpack

main.cc:

extern "C" void __libc_init_array();
extern "C" void Reset_Handler() { 
	__libc_init_array();
	while(true);
}

// Stubs:
extern "C" void _init() {}
extern "C" void abort() {}
extern "C" void *memcpy(void *dst, const void *src, unsigned n) {  return nullptr; }

Compilation and linking commands:

arm-none-eabi-g++ -O0 \
	-mcpu=cortex-m0 -march=armv6-m -mlittle-endian \
	-fno-unwind-tables -fno-exceptions \
	-ffreestanding -fno-rtti -fno-threadsafe-statics \
	-nostdlib -nostartfiles \
	-c main.cc -o build/main.o

arm-none-eabi-g++ \
	-Wl,--gc-sections \
	-Wl,-Map,build/test.map,--cref \
	-mcpu=cortex-m0 -march=armv6-m -mlittle-endian \
	-T link.ld \
	-nostdlib -nostartfiles \
	-o build/test.elf build/main.o

Compiling with these commands produces a 4kB binary. Output:

   text    data     bss     dec     hex filename
   4084       0     512    4596    11f4 build/test.elf

The map file reveals that lib_a-init.o references symbol __aebi_unwind_cpp_pr0, and thus the linker includes unwind-arm.o, libunwind.o and pr-support.o. This ends up being a little under 4kB of code added to the .text section.

Ive spent a fair amount of time googling around and trying to understand libc and all its options. I did find that if I define the symbol the linker wants to see, then the binary size drops to a reasonable size:

char __aeabi_unwind_cpp_pr0[0];

Produces this:

   text    data     bss     dec     hex filename
    136       0     520     656     290 build/test.elf

What makes me think this is somehow related to how the xpack version was compiled, is that when I use the official ARM release (v11.2), then I do not need to define __aeabi_unwind_cpp_pr0, and I still get a small binary with no libunwind linked in:

   text    data     bss     dec     hex filename
    120       0     512     632     278 build/test.elf

Additionally, the abort and memcpy stubs are not needed to link the project when using the official ARM gcc v11.2

If I remove the -fno-unwind-tables -fno-exceptions flags and compile with the official ARM version, then I get a similar sized binary (~4kB).

So it seems like the libc in the official ARM release respects whether I use -fno-exceptions or not, but the xpack version forces -fexceptions to be on.

Does anyone have an explanation for this?

[ilg-ul]

Hi Dan,

Thank you for your detailed report.

The intent was to follow the arm build in detail, but if you identified a difference, it is worth further investigating, especially since today I planned to make a new release with 11.3.

[ilg-ul]

I confirm the issue, with Arm 11.3 and my new xPack pre-release the result is the same as reported.

I'll further investigate and let you know when I have a fix.

[danngreen]

OK thanks!

[ilg-ul]

It is weird, but I think the problem is solved now.

In order to reduce size, the -nano libraries are compiled with an explicit -fno-exceptions, and I thought that using an explicit -fexceptions when compiling the regular libraries would enable exceptions when needed, but it seems that GCC understands it as always. :-(

After removing the explicit -fexceptions, the size is small again.

I'll cleanup the sources, test on all platforms, and provide you a pre-release for tests, hopefully in 1-2 days.

[danngreen]

Fast work, thank you, I look forward to testing it.

[ilg-ul]

With the just released 11.3:

   text    data     bss     dec     hex filename
     88       0     512     600     258 test.elf

[danngreen]

Excellent! Thank you again!

[ilg-ul]

Thank you for your help in improving the project!