[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20121127205116.1dbf130f.idunham@lavabit.com>
Date: Tue, 27 Nov 2012 20:51:16 -0800
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: musl 0.9.8 released
On Tue, 27 Nov 2012 22:39:48 -0500
Rich Felker <dalias@...ifal.cx> wrote:
> On Tue, Nov 27, 2012 at 06:43:29PM -0800, Isaac Dunham wrote:
> > arm: arm(eb), armel
> > mips: mips(32), mipsel(32)
> > microblaze: microblaze
> > (What's the status of microblazeel/microblazele? configure looks not
> > to recognize it...)
>
> It should work aside from configure not recognizing it. But I don't
> think it's been tested.
>
> > ppc: powerpc(32)
> >
> > Total arches:
> > 6
> > Total subarches (distinct ABIs):
> > 8-10 (depending on status of microblazeel and ABI compatability of
> > armhf with armel)
> >
> > -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?
> In the end, it might simply be the cleanest to just duplicate the
> trees, but use symlinks to eliminate most of the duplicate files.
> However, the interaction of that with install rules would have to be
> considered and the install rules might need revision.
<snip>
> > -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).
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...
> > 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)
--
Isaac Dunham <idunham@...abit.com>
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.
