From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1382 Path: news.gmane.org!not-for-mail From: James Bond Newsgroups: gmane.linux.lib.musl.general Subject: Re: bootstrap-linux patches for cross compilation to arm Date: Sun, 29 Jul 2012 00:42:21 +1000 Message-ID: References: <20120728125421.GU544@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b603b8a1100ea04c5e4d6c9 X-Trace: dough.gmane.org 1343486557 19668 80.91.229.3 (28 Jul 2012 14:42:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 28 Jul 2012 14:42:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1383-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jul 28 16:42:37 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Sv8Dx-0003tR-OH for gllmg-musl@plane.gmane.org; Sat, 28 Jul 2012 16:42:33 +0200 Original-Received: (qmail 3446 invoked by uid 550); 28 Jul 2012 14:42:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3437 invoked from network); 28 Jul 2012 14:42:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=UCHHGexdqzdh4M7MdLd4xn//gJLN4CpIcIRImvlPl7A=; b=drkpLytoLAj1hyd6803FE8J/irgMVyez9GMZjAZNONiArW4OL+A1efauhTsjfxkmqm qrHirfjAeOf6QbE1UXuQ4VfddkCWFGYH+Cj8xsV1SPWmHb2G3x8z/fqvCPOB8K70f9jW E0clCDJFGcQsOrzqjFwB3RV440Y8FYk8UjUZJUjz2DShmJYzUGkmWSIDxHduKBck1n7Z fpJigVDGzb6cTk02WdtY4U+3ws7O4CzXBH11xRtIPP2+y7gZj2//L/bleQAim96X8n7f /MChnFaBnn+9K/0Z0dUWDM5EO8pRHEG/JRX1lI0/OEBPC/yFm9twVaPgJAkfuYE9F6AT YD4A== In-Reply-To: <20120728125421.GU544@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:1382 Archived-At: --047d7b603b8a1100ea04c5e4d6c9 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 28, 2012 at 10:54 PM, Rich Felker 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. 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 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. Note the dependency complains is about raise/abort - not about printf, so it indicates (to me at least) that libc did get pull in earlier, but somehow gcc missed that it also needs to bring in the stack unwinding code. 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). Those host_configargs and --with-stage1-libs is a hack to get gcc/binutils configure test programs to compile so that libibery doesn't pull in more than what is needed. > > > - add linux-arm.config > > > > Some known issues: > > a) musl version as configured is at 0.9.2 but with arm it won't boot with > > 0.9.2 (busybox segfaults), you need to get the latest git master, make a > > tarball out of it and rename it to musl-0.9.2.tar.gz in the "src" > > directory. > > Do you know which bugfix solved this? It would be nice to mention in > the 0.9.3 release notes/announcement (hopefully in the next few days). > Thanks. I tested with commit 06650b968461b72d5eb44063dd68c176be330372 which is rather ancient in musl reckoning, it's the one with all John's patches merged in. I'd do a test with a more recent commit and get back to you. > > > This is my first post to the mailing list, so you feel this kind of stuff > > is out of topic, my apology and lesson learnt. > > Welcome to the list. This type of contribution to the list is > perfectly acceptable. > Thank you. cheers, James --047d7b603b8a1100ea04c5e4d6c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 28, 2012 at 10:54 PM, Rich Felker <= dalias@aerifal.cx> wrote:
On Sat, Jul 28, 2012 at 10:18:43PM +1000, James Bond wrot= e:
> - add host_configargs=3D"LIBS=3D-lc" and --with-stage1-libs= =3D-lc for native
> gcc/binutils compile so that they don't pull in *printf from libib= erty
> (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?
=A0
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 li= ke 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 li= bc can't be resolved unless we add "-lc" at the end.

One can easily exhibit the same problem using musl-cross too - just mak= e 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-musl= eabi -o hello hello.c" --- you will get a host of unsatisfied dependen= cy errors for raise, abort, etc basically the stack unwinding stuff. The pr= oblem is down the chain printf uses division, and division is done in libgc= c and can raise exception, thus the need for the stack unwinding code. To g= et it to compile, I found that I need to do "arm-linux-musleabi -o hel= lo hello.c -lc" instead.

Note the dependency complains is about raise/abort - not about printf, = so it indicates (to me at least) that libc did get pull in earlier, but som= ehow gcc missed that it also needs to bring in the stack unwinding code.
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 to= pic here).

Those host_configargs and --with-stage1-libs is a hack to get gcc/binut= ils configure test programs to compile so that libibery doesn't pull in= more than what is needed.
=A0

> - add linux-arm.config
>
> Some known issues:
> a) musl version as configured is at 0.9.2 but with arm it won't bo= ot with
> 0.9.2 (busybox segfaults), you need to get the latest git master, make= a
> tarball out of it and rename it to musl-0.9.2.tar.gz in the "src&= quot;
> directory.

Do you know which bugfix solved this? It would be nice to mention in<= br> the 0.9.3 release notes/announcement (hopefully in the next few days).
<= /blockquote>

Thanks. I tested with commit=A0 06650b968461b72d5eb440= 63dd68c176be330372 which is rather ancient in musl reckoning, it's the = one with all John's patches merged in. I'd do a test with a more re= cent commit and get back to you.
=A0

> This is my first post to the mailing list, so you feel this kind of st= uff
> is out of topic, my apology and lesson learnt.

Welcome to the list. This type of contribution to the list is
perfectly acceptable.

Thank you.

cheers,James

--047d7b603b8a1100ea04c5e4d6c9--