[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121128130507.GP20323@brightrain.aerifal.cx>
Date: Wed, 28 Nov 2012 08:05:07 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: musl 0.9.8 released
On Tue, Nov 27, 2012 at 08:51:16PM -0800, Isaac Dunham wrote:
> > > -planned subarches: mipsel32-sf, mips32-sf
> >
> > My idea for the names would be something like: mips, mipsel, mips-sf,
> > mipsel-sf, ...
>
> > Basically, the full arch name would be something along the lines of:
> >
> > arch[el|eb][-abivariant]
> >
> > which could be represented as $(ARCH)$(ENDIAN)$(ABIVARIANT), where
> > only $(ARCH)$(ABIVARIANT) and $(ARCH) should be needed to search for
> > asm files. But additional considerations need to be made for how the
> > main arch dir with bits headers and internal headers would be
> > selected. I don't think we want to duplicate entire arch trees for
> > subarchs, but I also don't see how subarchs can get by with using the
> > same set of headers unless we rely on the compiler to predefine macros
> > that distinguish them. This is rather ugly but we're already partially
> > relying on it for endianness varants.
>
> Where would the headers need to differ by subarch?
> I'm guessing this is mainly stuff like fenv?
Yes, probably the floating-point headers are the main places: fenv.h,
float.h, and math.h.
> > > -unsupported subarches: i386
> >
> > ??
> The 80386 processor, as opposed to 80486.
>
> # On x86, make sure we don't have incompatible instruction set
> # extensions enabled by default. This is bad for making static binaries.
> # We cheat and use i486 rather than i386 because i386 really does not
> # work anyway (issues with atomic ops).
This is fairly comparable to the mips1 issue and the need for ll/sc
emulation by the kernel. i386 is just fundamentally lacking in a way
that makes multi-tasking/multi-threading not workable with the POSIX
apis for it. The kernel should be emulating 'lock cmpxchg', like it
does ll/sc for mips1, and if it did, 386 would work fine. But
apparently nobody cares anyway..
> Also, I can't seem to find it now, but somewhere I heard that
> upstream gcc and/or glibc with the "i386-linux-*" triplet has some
> incompatability with "i486-linux-*". IIRC, I heard that some distros
> patch this to treat i386-linux-* as if it meant i486.
> But, I can't trace the source for that claim, so don't count on it...
This doesn't make any sense to me.
> > > It seems Debian's using aarch64-* for ARMv8.
> >
> > Yes, 64-bit arm is a new arch and it seems they used the name aarch64
> > instead of arm64 due to arm* being interpreted as 32-bit arm by many
> > things..
> >
> ie, due to the insane number of ABIs and triplets that ARM has?
> arm (bigendian/OABI), armeabi (bigendian: armeb), armel
> (littleendian variant of EABI), armhf (armel + vfp3)
:-)
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.
