This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [ARM] architecture specific subdirectories, optimised memchr and some questions
On Thu, 4 Aug 2011, David Gilbert wrote:
> To try and straighten those out here are some more questions:
> a) For a build without specifying the CPU should machine=arm and
> submachine="" ?
The practice for other processors (based on the target triplet) would be
machine=arm, base_machine=arm, submachine="" (and machine=arm/eabi given
the "eabi" subdirectory structure).
> b) If the user wants to specify the CPU architecture should they be
> using the triplet - i.e.
> should they be using armv7-linux-gnueabi (Or is that
> armv7a-linux-gnueabi?) -
> and would that have machine=armv7a and submachine="" ?
armv7- would be existing practice, and would give machine=arm/armv7 (or
right now, arm/eabi/armv7), base_machine=arm and submachine="". This
needs config.sub (maintained in the separate config.git) to be updated to
handle armv7 (and v6) consistently.
> c) Is submachine for CPU varients - e.g. if I wanted to compile for
> a cortex-a8 would
> I be compiling with --with-cpu=cortex-a8 and somehow expect
> machine=armv7a
> submachine=cortex-a8 ?
You'd compile --with-cpu=cortex-a8 and *also* use the armv7- triplet. Or
simply set CC to include the -mcpu=cortex-a8 value (along with using the
appropriate target triplet) and not bother with --with-cpu= unless there
are actually sysdeps files for the particular CPU.
> d) What happens for big endian - doesn't that have a triplet like
> armeb-linux-gnueabi
> and then what is $machine?
sysdeps/arm/preconfigure should probably convert triplets to a canonical
form when computing the machine value - so armv7b- would end up using the
armv7/ directory.
> > Otherwise, while ports has historically been used as a dumping ground for
> > random code removed from libc, I don't think that's the right approach; we
> > have version control to preserve old versions of code and ports should
> > have those ports of glibc that aren't in libc but are reasonably close to
> > a working state, not code that's been broken or obsolete for a long time.
> > By now I think it would be reasonable to remove all the old-ABI ARM code
> > from ports, so moving the eabi code up a directory level and eliminating
> > the complexities of claiming to support two different ABIs. ?(The only
> > ports that I think are in some semblance of a maintained state are alpha,
> > arm/eabi, hppa, m68k, mips, powerpc - all of them for Linux only at
> > present.)
>
> Would you want that clean up as a prerequisite for this patch?
No.
> > Has it been tested (with the glibc testsuite) for both big and little
> > endian?
>
> Certainly not for big endian; I did a self contained test for that -
> using a binutils+eglibc+gcc set - I do not have
> a full armeb chroot to test that against; what's the best way of doing that?
> In little endian it did run the testsuite.
It's probably possible to run the string tests using QEMU userspace
emulation without needing a full bootable filesystem.
> Are these 3 on the basis that some optimised routine somewhere in libc
> will be explicitly wanting a fused multiply add or that this should happen
> for any libc routine that happens to be doing multiply/add ? I'm not sure how
> you would do the later with ifunc.
They are on the basis that the standard functions fmaf/fma/fmal should be
(a) correct and (b) optimal. glibc 2.13 made them correct as long as you
have hardware exception and rounding mode support; my notes were on how to
make them optimal subject to being correct.
--
Joseph S. Myers
joseph@codesourcery.com