[PATCH] Fix building statically linked ARM EABI applications (fwd)

Hans-Peter Nilsson hans-peter.nilsson at axis.com
Thu Oct 1 18:17:28 UTC 2009


(Once more, for the list, after subscribing.  Pardon the
duplicate, Joseph and Ricard.  If I'm misinformed below, your
enlightenments are welcome.)

Sorry for breaking the threading here, responding to a forwarded
replied-to message.

> Date: Tue, 22 Sep 2009 17:38:06 +0200
> From: Joseph S. Myers <joseph at codesourcery.com>
> To: Ricard Wanderlöf <Ricard.Wanderlof at axis.com>
> Cc: uClibc mailing list <uclibc at uclibc.org>
> Subject: Re: [PATCH] Fix building statically linked ARM EABI applications
> 
> On Tue, 22 Sep 2009, Ricard Wanderlof wrote:
> 
> >>> /trees/prod1/target/armv5-axis-linux-gnueabiucl
> >>> ibc/lib/libc.a(sigrestorer.os):(.ARM.exidx+0x0): undefined reference to
> >>> `__aeabi_unwind_cpp_pr1'
> >>>
> >>> This can be fixed with the following patch. Doesn't seem to have any
> >>> detrimental effects. Anyone think of a reason this couldn't be commited?
> >>
> >> Yes, this function is defined in libgcc_eh.a and the libc version is a dummy
> >> version that is *incorrect* for programs requiring unwinding and should only
> >> be used internally in libc.  If it's not in your libgcc_eh.a or that is not
> >> being searched, your toolchain is misconfigured.

I understand the patch is not accepted, so we'll keep it local
(no unwinding here), but I'd like to add some details and maybe
there are reasons to not use aeabi_unwind_cpp_pr1.c *at all*:

I admit the (linker) invocation is lacking -lgcc_eh, but neither
the original program nor the simpler case 'int main(void) {
abort();}' require unwinding.  The static linking part was meant
as a sanity build-time test, nothing else.

For the invocation, a script is used, that passes -nostdlib to
arm-gcc and picking libraries and startup files "manually" from
a build-tree.  Note, sigrestorer.os is the *only* referer of
__aeabi_unwind_cpp_pr1.  The reference is created by gas due to
the pseudo-ops in sigrestorer.S; there's no actual exception
referer.  A little bit of EABI magic.

I suggested the patch, because it doesn't seem that it would
break anything, at least nothing that wasn't already broken.  I
mean, if a signal is thrown from within uclibc and the exception
table in sigrestorer.S was to be used (mind you, signals can be
translated into exceptions for some targets, apparently
including ARM) and __aeabi_unwind_cpp_pr1 is actually needed,
then stubbing it in the shared uclibc by aeabi_unwind_cpp_pr1.c
is the wrong thing.  For all other uses, -lc normally is
included only *after* -lgcc -lgcc_eh/-lgcc_s so those functions
wouldn't be picked even in the static library - unless you hack
your gcc invocation to leave out -lgcc_eh or the equivalent, in
which case TRT happens.

> > But then how come the libc version is included at all in the shared version of
> > the library?
> 
> This is explained in the comments in the relevant source file.  Note that
> it is hidden and not exported from libc.
> 
> /* Because some objects in ld.so and libc.so are built with
>     -fexceptions, we end up with references to this personality
>     routine.  However, these libraries are not linked against
>     libgcc_eh.a, so we need a dummy definition.   This routine will
>     never actually be called.  */

Perhaps it's primarily due to sigrestorer.os rather than
-fexceptions?

brgds, H-P


More information about the uClibc mailing list