This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: PowerPC E500 port
On Mon, 8 Oct 2007, Roland McGrath wrote:
> The glibc norm is that host triplet and --with-fp setting are what specify
> the ABI the glibc build will support. The --with-cpu setting affects what
My understanding was that the ABI was effectively determined by the
compiler being used, where hard and soft-float have incompatible ABIs (as
on Power and MIPS) - if the glibc configuration disagrees (in particular
if glibc is configured for hard float but the compiler is using the
soft-float ABI) you'll get a broken glibc (or if lucky an assembler
error).
Determination from the compiler is explicit for mips64*, where the
compiler options are examined in preconfigure to determine the particular
ABI (and different host triplets for the different ABIs simply aren't
used). Likewise for m68k where the compiler behavior is examined to
distinguish ColdFire (which has a different ABI as well as being an
instruction set variant) from m680x0; again there is no separate host
triplet. (Core libc probably has fewer such cases of multiple
incompatible ABI and CPU variants.)
> hardware the glibc being built can run on, but it may not affect the ABI.
> The powerpc32 soft-float ABI is indicated by powerpc-*-linux --without-fp.
> If powerpc-*-linux --with-cpu=e500 will produce that ABI, it must be
> synonymous with powerpc-*-linux --without-fp --with-cpu=e500.
I should note that while --with-cpu for glibc implies passing a -mcpu
option to GCC, there is no such GCC option as -mcpu=e500 - the options are
-mcpu=8540 and -mcpu=8548. But while 8540 is E500v1 and 8548 is E500v2,
those options are synonymous - the actual E500v2 features are enabled with
-mfloat-gprs=double (or by configuring GCC appropriately - a
configure-time option not a different target triplet - to default that
way).
Now the host triplet used when configuring glibc need bear no resemblence
to the target triplet used when configuring GCC - just as it's possible to
build an i686-pc-linux-gnu glibc with x86_64-pc-linux-gnu-gcc -m32, a
powerpc-none-linux-gnuspe glibc could be built with a compiler using
another target triplet and appropriate options to select an E500 CPU and
ABI. So perhaps configuring based on powerpc*-linux*spe as the configured
host triplet would be the simplest approach after all (and avoid questions
of whether the ABI with different <fenv.h> constants is or is not
different from the soft-float ABI), with compiler test or --with-cpu only
to distinguish E500v1 and E500v2? Because of the lack of -mcpu=e500, the
"e500" sysdeps directories could not be accidentally selected by a
--with-cpu option.
> Your use of soft-fp seems fine to me as far as organization. Does that
> interact correctly with sysdwps/powerpc/soft-fp/?
With the one in ports or the one in libc, or both?
With the one in ports (overriding its sfp-machine.h), yes I think so.
With the one in libc, there's a serious question of what's "correct".
Recall that one does
feq ($(subdir),soft-fp)
ifeq ($(sizeof-long-double),16)
powerpc-quad-routines := q_add q_cmp q_cmpe q_div q_dtoq q_feq q_fge \
q_fgt q_fle q_flt q_fne q_itoq q_mul q_neg q_qtod q_qtoi \
q_qtos q_qtou q_qtoull q_qtoll q_sqrt q_stoq q_sub q_utoq \
q_ulltoq q_lltoq q_util
sysdep_routines += $(powerpc-quad-routines)
endif
endif
and those functions are declared with GLIBC_2.2 version. Now:
* glibc 2.2 would not have generally been built with compilers with
128-bit long double, so the function wouldn't really have been in the 2.2
ABI, so that version seems wrong.
* q_utoq.c actually defines a function called _q_uitoq instead of the
function _q_utoq in the Versions file.
* If those functions do get built then they still wouldn't meet the 1995
SysV ABI they are meant to meet: they are meant to be functions for IEEE
long double, which has a different argument-passing ABI from IBM long
double which current compilers use (and they aren't built with
-mabi=ieeelongdouble, if that even works on GNU/Linux).
* I believe those quad functions (though in libc not ports) only ever get
built in the soft-float case; the sysdeps/powerpc/soft-fp directory
doesn't get used in hard-float builds (it's not in any relevant Implies
file). That 1995 ABI is purely a hard-float ABI.
So the _q_* functions are not part of the soft-float ABI for which they
are built, and are not built compatibly with the ABI they are part of, nor
would they have been built in the glibc version corresponding to their
symbol versions because of lack of 128-bit long double support. The
current project to document the de facto 32-bit GNU/Linux Power ABIs would
be unlikely to document these functions that form no useful part of the
current ABIs. Frankly I think they are best removed from glibc as no
program could ever have used them successfully in the form they presently
exist.
--
Joseph S. Myers
joseph@codesourcery.com