[PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind

[Joseph S. Myers]

On Wed, 13 Jun 2012, Fredrik Hederstierna wrote:

> >You need to provide a self-contained explanation of what the problem
> >is  that your patch is fixing and why you chose that approach to
> >fixing it -  with reference to the ARM EABI documentes (RTABI etc.)
> >for why your  approach is valid according to the ARM EABI.  libunwind
> >is a library separate from libgcc that is used by libgcc for
> >unwinding on ia64-linux-gnu only (whether built by GCC or separately
> >installed).  There is also a separate libunwind project that may be
> >used  on GNU/Linux platforms but I am not aware of being used for
> >bare-metal at  all.
> 
> Our experience is that when using simple integer division in your code,
> the libgcc division routine will includes div-zero handling (exception support?),
> which will include dependencies to libunwind. This dependency problem
> is the background of the patch.

What do you mean by "dependencies to libunwind"?

As I explained, libunwind is a separate library that GCC should never be 
building or using for platforms other than IA64 GNU/Linux.  The _Uwind_* 
functions are *not* libunwind functions on ARM EABI, they are functions 
from libgcc_eh.  The __aeabi_unwind_cpp_pr* personality routines are *not* 
libunwind functions either, they are also functions from libgcc_eh.  
Anything related to those functions should not use the term "libunwind", 
whether in configure option names, or patch submissions, since it is not 
libunwind.

Linking with libgcc_eh should work fine by default; no special action 
should be needed to link in whatever unwind functions your code 
references.  But if you don't want to link them in at all, and if defining 
your own versions of __aeabi_div0 / __aeabi_ldiv0 doesn't suffice, then as 
long as your code doesn't raise exceptions it should be safe for you to 
stub out the __aeabi_unwind_cpp_pr* functions.

-- 
Joseph S. Myers
joseph@codesourcery.com