Forum: ARM programming with GCC/GNU tools exception handling code in binary from pure C code

Author: Bart G. (Company: greenpeak) (bago)
Posted on:

Rate this post
0 useful
not useful

I tried out yagarto to generate code for a cortex-M3 (STM32).
I got it working, but I was surprised a whole bunch of exception 
handling code ends up in my binary (the source code is pure C)

This happens both with my (complex) program, and the STM3210ETest small 
example project (yagarto howto page, STM32), if I add this small 
unsigned long long xyz(unsigned long a, unsigned long long b )
    return a/b;

If i check the library, there are some .ARM.extab/.ARM.exidx sections in 
the 64-bit division code:
$ arm-none-eabi-objdump.exe -h yagarto/lib/gcc/arm-none-eabi/4.5.1/thumb/v7m/libgcc.a 
udivdi3.o:     file format elf32-littlearm

Idx Name          Size      VMA       LMA       File off  Algn
  6 .ARM.extab    00000000  00000000  00000000  00000ba5  2**0
  7 .ARM.exidx    00000008  00000000  00000000  00000ba8  2**2
some googling learned these are indeed related to exeption handling.
Isn't there a way to get rid of all this excpetion handling overhead?
-fno-exceptions did not work. DISCARD them in the linker script also 
did not work


Author: Jörg W. (dl8dtl) (Moderator)
Posted on:

Rate this post
0 useful
not useful
I don't know the answer (sorry), but before you're wasting too much
time into it: please note it's a total of 8 (yes, eight) bytes you
are worrying about.

Author: Bart G. (Company: greenpeak) (bago)
Posted on:

Rate this post
0 useful
not useful
Hi Jörg,

those 8 bytes (entry in exception unwind table) are not the problem;
the problem is the exception recovery code itself.

The .text section in the STM3210ETest sample project explodes from 
0x0b2c to 0x3004 bytes, that's almost 10KB!!

To be clear: I'm talking about c++ type software exceptions, not ARM 
(HW) exceptions

The linker option -t shows what is included from libraries:
c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe: mode armelf
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/thumb/v7m\libgcc.a)_arm_addsubdf3.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/thumb/v7m\libgcc.a)_arm_truncdfsf2.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/thumb/v7m\libgcc.a)_arm_addsubsf3.o
up to here it is normal. Everything that follows is only linked in if 
there is a 64-bit division:
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/thumb/v7m\libgcc.a)_aeabi_uldivmod.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/thumb/v7m\libgcc.a)bpabi.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/thumb/v7m\libgcc.a)unwind-arm.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/thumb/v7m\libgcc.a)libunwind.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/thumb/v7m\libgcc.a)pr-support.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/thumb/v7m\libgcc.a)_dvmd_tls.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/thumb/v7m\libgcc.a)_divdi3.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/thumb/v7m\libgcc.a)_udivdi3.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/thumb/v7m\libgcc.a)_udivsi3.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/lib/thumb/v7m\libc.a)lib_a-abort.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/lib/thumb/v7m\libc.a)lib_a-memcpy.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/lib/thumb/v7m\libc.a)lib_a-reent.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/lib/thumb/v7m\libc.a)lib_a-signal.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/lib/thumb/v7m\libc.a)lib_a-signalr.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/lib/thumb/v7m\libc.a)lib_a-freer.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/lib/thumb/v7m\libc.a)lib_a-impure.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/lib/thumb/v7m\libc.a)lib_a-mallocr.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/lib/thumb/v7m\libc.a)lib_a-mlock.o
(c:/program files/yagarto/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/lib/thumb/v7m\libc.a)lib_a-sbrkr.o

Linked in code is various unwind functions from libgcc, e.g.
20000f60 t _Unwind_SetGR
20000f7c t __gnu_unwind_pr_common
unwind = stack unwind = recovering from a exception.
These function draw in a whole bunch of os-type libc functions.

if you think you can help I can try to create a small program that 
reproduces the issue, but it should be fairly simple: just add the 
division function to any existing code (without exception handling)
note: the linked in code also forces you to define os-type backends such 
as _exit, _getpid, _kill,_sbrk.

Author: Jörg W. (dl8dtl) (Moderator)
Posted on:

Rate this post
0 useful
not useful
In that case, your only chance is to recompile that library without
exception handling, I guess.  You might ask the Yagarto folks
about that, as I understand it's them who are performing the actual
compilation of the library.

Author: Bart G. (Company: greenpeak) (bago)
Posted on:

Rate this post
0 useful
not useful
Do you know how to best contact the yagarto people?
For support they point to this site.

I found this interesting post:
> by Segher Boessenkoolon 2009-10-26T18:30:00+00:00.
>> So, can I get gcc without unwind at all? I really only need the C
>> compiler and no unwind exceptions.
> As far as I can see, the ARM libgcc division routines always require
> unwinding support. To get around that, I use an evil hack: put this
> char __aeabi_unwind_cpp_pr0[0];
> in a C file that you link before libgcc, and none of the unwinder
> stuff will be pulled in. Your program will of course die horribly
> when you divide by zero ;-)

This indeed works!

This is a very ugly hack of course, and I think there is still something 
wrong with the (selected) library, but i don't know much about how that 

I think the root of the problem is in 
gcc-4.5.1/gcc/config/arm/lib1funcs.asm , or in the options used to 
compile that file.

But the hack is sufficient for me.


Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]

Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.