This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind
-----Joseph Myers <joseph@codesourcery.com> wrote: -----
>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.
Ah, ok, now I understand. The problem is rather the new dependency
from libgcc to libgcc_eh then. My mistake, I thought UnWind-calls was
related to libunwind, but as you explained now its libgcc_eh.
Sorry for my ignorance.
So, since we build toolchain with --disable-shared, the libgcc_eh.a
will not be built. This makes linking to libgcc_eh not possible.
Somehow also when building libgcc with -fexceptions it will make
references to abort() and memcpy(), but this is maybe related.
> 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.
Ok, so the solution for us it to stub out the __aeabi_unwind_cpp_pr* functions then.
This seems to me as a hack, since we build just a plain C bare-metal GCC,
I would rather see a solution where dependencies to libgcc_eh could be removed completely.
Something like the suggested patches, but then with renaming of 'libunwind' to 'libgcc_eh'.
Thanks and Best Regards,
Fredrik