-march

-march

[stephen Turner]

[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]

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.

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.

thanks,
stephen

[-- Attachment #2: Type: text/html, Size: 1176 bytes --]

Re: -march

[Rich Felker]

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.

> 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

Re: -march

[stephen Turner]

[-- Attachment #1: Type: text/plain, Size: 2161 bytes --]

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 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,

[-- Attachment #2: Type: text/html, Size: 2970 bytes --]