[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120728203703.GV544@brightrain.aerifal.cx>
Date: Sat, 28 Jul 2012 16:37:03 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: bootstrap-linux patches for cross compilation to arm
On Sun, Jul 29, 2012 at 12:42:21AM +1000, James Bond wrote:
> On Sat, Jul 28, 2012 at 10:54 PM, Rich Felker <dalias@...ifal.cx> wrote:
>
> > On Sat, Jul 28, 2012 at 10:18:43PM +1000, James Bond wrote:
> > > - add host_configargs="LIBS=-lc" and --with-stage1-libs=-lc for native
> > > gcc/binutils compile so that they don't pull in *printf from libiberty
> > > (which segfaults).
> >
> > Do you have any idea why this is needed? Are they always pulled in
> > (and just don't segfault on other archs), or is pulling them in
> > arm-specific?
> >
>
> This seems to be a problem in arm only. Unpatched bootstrap will build
> cross x86-64 --> x86 rootfs and native toolchain fine, no problem.
>
> The problem so far looks like this: some of the helper functions in libgcc
> raises exceptions; and the code for these exceptions in libc (also musl).
> But when using static libc, libc is linked in first before libgcc, thus
> libgcc's dependencies on libc can't be resolved unless we add "-lc" at the
> end.
Are you sure this is how the workaround is working? Adding -lc is most
likely to take place at the beginning, not the end. Default libs
provided by the compiler come last.
> One can easily exhibit the same problem using musl-cross too - just make
> sure that musl-cross build a toolchain with static musl libc (instead of
> the default dynamic libc). Then compile "#include <stdio.h> void main() {
> printf("hello %d\n"); }" with "arm-linux-musleabi -o hello hello.c" --- you
> will get a host of unsatisfied dependency errors for raise, abort, etc
> basically the stack unwinding stuff. The problem is down the chain printf
> uses division, and division is done in libgcc and can raise exception, thus
> the need for the stack unwinding code. To get it to compile, I found that I
> need to do "arm-linux-musleabi -o hello hello.c -lc" instead.
This is stupid; there's no reason for the division to raise signals or
generate exceptions. Integer division by zero results in undefined
behavior, so libgcc can just do nothing special when it happens. Or it
could just execute an instruction that will raise a synchronous signal
(like an illegal opcode) rather than making library calls.
Floating point division by zero has well-defined results and raises a
floating point exception on implementations that support floating
point exceptions, but ARM EABI does not support them, and therefore
there's nothing special to be done (and even if there were, it would
not involve signals or C++ exceptions, just raising flags).
It would be really nice to fix this issue at the gcc level since it's
significantly bloating applications with code that do not, and should
not, need.
> The end result is without adding those parameters, libiberty configure will
> fail to detect that musl has *printf (because compilation fails), and thus
> pulls in its own version (which crash but that's totally out of topic
> here).
I see. That makes sense.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
