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


Joseph S. Myers wrote:
> 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).
>
>   
Not exactly. The ABI is the combined effort of the compiler (register
usage, parm passing, frame stacking, ...) the kernel (environment, aux
vector, ucontext, ...) and the runtime (ld.so, setjmp/__longjmp,
*context, dl-trampolien.S, ...)

We get a lot of notes/IRC traffic about broken PPC glibc builds. I would
prefer reducing the the posibility of new failure modes.

> 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).
>
>   
So :

    --target=powerpc-*-linux-gnuspe
    --without-fp

and optionally:

    --with-cpu=[8540|8548]

If e500 is never a valid -mcpu= target, then powerpc/powerpc32/e500 is
less objectionable, but I still think powerpc/e500/ is clearer. So

    $machine=powerpc/powerpc32/e500

And the none FPU code would live in

    ./sysdeps/powerpc/powerpc32/e500

and soft-fp API code in

    ./sysdeps/powerpc/powerpc32/e500/nofpu

if there is any ./sysdeps/powerpc/powerpc32/e500/fpu directories then
they can only be reached via Implies within a  ./e500/nofpu directory.
Any SPE fpu code in this directories should be guarded with AT_HWCAP
checks (PPC_FEATURE_HAS_EFP_SINGLE & PPC_FEATURE_HAS_EFP_DOUBLE) at runtime.

otherwise: -with-cpu=[8540|8548] can be used to add CPU-TYPE specific
SPE-single/double optimizations from directories:

    ./sysdeps/powerpc/powerpc32/e500/[8540/8548]/nofpu

./e500/8548/nofpu would contain Implies back to ./e500/8540/nofpu so it
can share SPE-single code with 8540, but provide hardware implemented
overides for SPE-double. Code in these directores don't need AT_HWCAP
guards because the configuration is specifically targeting those chips.

This is similar  to how the 
--with-cpu=[power4|970|power5|power5+|power6|power6x] source is arranged.
> 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:
>
>   
I agree we should remove that as not used.


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