Discussion:
Option to build bare-metal ARM cross-compiler for arm-none-eabi target without libunwind
(too old to reply)
Fredrik Hederstierna
2012-06-13 07:29:20 UTC
Permalink
-----Joseph Myers <***@codesourcery.com> 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.

Since libunwind does use eg. memcpy() and abort() we cannot link since we have our
own custom versions of all libc functions, a real bare-metal toolchain.

>Certainly it would be unusual to use it for ARM
>EABI and the ARM EABI libgcc works fine without it. So referring to
>libunwind in the ARM EABI context seems rather confusing; if you
>don't want it, just do the same as almost all other ARM EABI users
>and don't use it; it's *using* libunwind that requires special
>action, not avoiding it.

We don't use it, and we do not want to use it.
But we use division libc functions. And the the libgcc division functions are
compiled with -fexceptions, so we will get libunwind dependecies anyway.
The patch does make this dependency optional.

If you want I can submit you with some example scripts how we build our toolchain and
some simple code to show what is our problem.
(You can also check the Rockbox project that have the same problem. See previous posts from other people.)

Best Regards
Fredrik Hederstierna
Fredrik Hederstierna
2012-06-13 07:35:42 UTC
Permalink
This is the link to the original patch.
It contains some background information and more links.

http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00720.html

The patch is now updated and improved by Larry Doolittle.
/Fredrik
Julian Brown
2012-06-13 10:29:30 UTC
Permalink
On Wed, 13 Jun 2012 09:35:42 +0200
Fredrik Hederstierna <***@securitas-direct.com> wrote:

> This is the link to the original patch.
> It contains some background information and more links.
>
> http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00720.html
>
> The patch is now updated and improved by Larry Doolittle.
> /Fredrik

Related:

http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01618.html

That one only handles 64-bit division (I don't know if there are other
things which pull in the unwinder), and is probably quite bitrotten by
now -- it never got approved/committed. Sorry about that!

Cheers,

Julian
Joseph S. Myers
2012-06-13 10:38:50 UTC
Permalink
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
***@codesourcery.com
Fredrik Hederstierna
2012-06-13 11:03:26 UTC
Permalink
-----Joseph Myers <***@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
Fredrik Hederstierna
2012-06-13 11:49:19 UTC
Permalink
> 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

Ok, just read the "Exception Handling ABI for the ARM Architecture".

* From Section 6.2

"Bits 24-27 select one of 16 personality routines defined by the run-time support code. Remaining bytes are data
for that personality routine.
...
ARM has allocated index numbers 0, 1 and 2 for use by C and C++.
...
Object producers must emit an R_ARM_NONE relocation from an exception-handling table section to the required
personality routine to indicate the dependency to the linker."

I think you are right, we need to stub out the __aeabi_unwind_cpp_pr functions.

Thanks alot & Best Regards
Fredrik
Continue reading on narkive:
Loading...