This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]