This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]