This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
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.