From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6861 Path: news.gmane.org!not-for-mail From: stephen Turner Newsgroups: gmane.linux.lib.musl.general Subject: Re: -march Date: Sat, 17 Jan 2015 18:31:31 -0500 Message-ID: References: <20150117222047.GZ4574@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1138e31838a481050ce17dfd X-Trace: ger.gmane.org 1421537506 25880 80.91.229.3 (17 Jan 2015 23:31:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Jan 2015 23:31:46 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6874-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jan 18 00:31:45 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YCcqH-0007Xz-Ll for gllmg-musl@m.gmane.org; Sun, 18 Jan 2015 00:31:45 +0100 Original-Received: (qmail 21728 invoked by uid 550); 17 Jan 2015 23:31:44 -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 21714 invoked from network); 17 Jan 2015 23:31:43 -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=R9TWRikY8n9oGzlfi7sBqjsZidlfg8oUfyD0wvYi+qQ=; b=Ne73U5GCQ7pE4L3Ghel7ThRiPn+BSD9aNzdNIs5NntVZdJe0XsifD705EGfZB4Rny7 cOov4OoKEWW50h0WpagQQOsOkTEpvUfKkQm3Krroapox4phygPzPlBocd5yIEEr78A5Y P7ixy+exvfHADp6noOIwJTVCeJlTLrb1A1brBYOG30TaV6Kx6BaHnbmYvRLkCXBZjtjq HxHCIzFSYs0Ayrq2YvTsDfxO1D61nEIPOzahsc4knsVA10tV2XFbTxzd/7Lf1BeV+YDX NIsDpVmjiURtLrjO7lZAdF1ZOVlCHwViM4E9aRojO6uuf+Av1WDFSLYO/eVWsCLt4t8y OrZA== X-Received: by 10.170.120.195 with SMTP id m186mr3968498ykb.27.1421537491590; Sat, 17 Jan 2015 15:31:31 -0800 (PST) In-Reply-To: <20150117222047.GZ4574@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:6861 Archived-At: --001a1138e31838a481050ce17dfd Content-Type: text/plain; charset=UTF-8 On Sat, Jan 17, 2015 at 5:20 PM, Rich Felker wrote: > On Sat, Jan 17, 2015 at 05:10:40PM -0500, stephen Turner wrote: > > So i have been allowing musl to auto detect/compile and it seems to have > > always selected i386 by default. I wanted to build it for 686 and noticed > > the --target= didnt seem to do it on my system I specified -march to > cflags > > and it still shows i386 for the link. The link is supposed to change > > correct? IE ld-musl-$ARCH.so.1? it appears on my debian vm to always be > > ld-musl-i386.so.1 is it instead pulling the $ARCH var from somewhere off > my > > debian system instead of what it was compiled for? > > > > as far as the actual code in the libs, it could have been built in i686 > > form both times but i did not try to check it by any means other than > > glancing at the link. I know the -march=i686 was passed during the > compile > > process though. while watching the compile output stream by. > > If you want a different -march, just put it in the CFLAGS you pass to > configure and it will be honored. This does not change $ARCH or the > name of the dynamic linker, because either way musl is providing the > exact same ABI, which we call "i386". If you build musl with > -march=i686, you won't be able to use the libc.so/ld-musl (or any > binaries static-linked with it) on a pre-686-class x86, but it's still > compatible with exactly the same application binaries. > > Out of curiosity, with musl is there a noticeable benefit to compiling i686 instead of i486? If not then i may just stick to 486 which is the oldest supported by newer kernels. > > Im not sure exactly what is going on at the moment, im assuming i may not > > be doing something right? A readelf output said the machine is intel > 80386 > > (In the event thats pointing to my processor im running a quad 64 bit > amd) > > > > thanks for any help and insight. > > On some archs, extended headers encode the minimum cpu model needed to > use the binary. This is not done on x86 as far as I know. If the cpu > is too old to support some instructions in the binary, you'll just get > SIGILL at runtime. > > Rich > Thanks, --001a1138e31838a481050ce17dfd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sat, Jan 17, 2015 at 5:20 PM, Rich Felker <dalias@libc.org> wrote:
On Sat, Jan 17, 2015 at 05= :10:40PM -0500, stephen Turner wrote:
> So i have been allowing musl to auto detect/compile and it seems to ha= ve
> always selected i386 by default. I wanted to build it for 686 and noti= ced
> the --target=3D didnt seem to do it on my system I specified -march to= cflags
> and it still shows i386 for the link. The link is supposed to change > correct? IE ld-musl-$ARCH.so.1? it appears on my debian vm to always b= e
> ld-musl-i386.so.1 is it instead pulling the $ARCH var from somewhere o= ff my
> debian system instead of what it was compiled for?
>
> as far as the actual code in the libs, it could have been built in i68= 6
> form both times but i did not try to check it by any means other than<= br> > glancing at the link. I know the -march=3Di686 was passed during the c= ompile
> process though. while watching the compile output stream by.

If you want a different -march, just put it in the CFLAGS you pass t= o
configure and it will be honored. This does not change $ARCH or the
name of the dynamic linker, because either way musl is providing the
exact same ABI, which we call "i386". If you build musl with
-march=3Di686, you won't be able to use the libc.so/ld-musl (or any
binaries static-linked with it) on a pre-686-class x86, but it's still<= br> compatible with exactly the same application binaries.


Out of curiosity, with mu= sl is there a noticeable benefit to compiling i686 instead of i486? If not = then i may just stick to 486 which is the oldest supported by newer kernels= .
=C2=A0
> Im not sure exactly what is going on at the moment, im assuming i may = not
> be doing something right?=C2=A0 A readelf output said the machine is i= ntel 80386
> (In the event thats pointing to my processor im running a quad 64 bit = amd)
>
> thanks for any help and insight.

On some archs, extended headers encode the minimum cpu model needed = to
use the binary. This is not done on x86 as far as I know. If the cpu
is too old to support some instructions in the binary, you'll just get<= br> SIGILL at runtime.

Rich

Thank= s,=C2=A0

--001a1138e31838a481050ce17dfd--