multilib question

[Till Straumann]

Ralf Corsepius wrote:
> On Thu, 2005-11-10 at 09:07 -0800, Till Straumann wrote:
> 
>>Ralf Corsepius wrote:
>>
>>>On Wed, 2005-11-09 at 22:06 -0800, Till Straumann wrote:
>>>
>>>
>>>>I want to build gcc/newlib with the following variants:
>>>>
>>>>-mcpu=860 -soft-float
>>>>-mcpu=603e -Dmpc8260
>>>>-mcpu=604
>>>>-mcpu=7400 -mabi=altivec -maltivec -mvrsave=yes
>>>>-mcpu=7400 -mabi=altivec -maltivec -mvrsave=no
>>>>-mcpu=7400 -mabi=altivec -mno-altivec
>>>>
>>>>how do I have to set the MULTILIB_xxx variables in 't-rtems' ?
>>>
>>OK, let me simplify my question:
>>
>>I want something like MULTILIB_EXTRA_OPTS but it should only
>>apply to one specific variant. E.g., -mcpu=7400 should always
>>activate -mabi=altivec but -mabi=altivec should not be active
>>on other cpus.
> 
> Generally speaking, this means adding an extra element to the vector of
> multilibs.
> 
> I.e.
> * to extend MULTILIB_OPTIONS and MULTILIB_DIRNAMES by one element,
> * to extend MULTILIB_EXCEPTIONS to remove all those permutations of
> flags you don't want.

That's what I'm currently experimenting with. However, it makes the
directory tree deeper...

I.e., if I only had

MULTILIB_OPTIONS    = mcpu=7400 mno-altivec
MULTILIB_DIRNAMES   = m7400 novec
MULTILIB_EXTRA_OPTS = mabi=altivec
MULTILIB_EXCEPTIONS = mno-altivec

I would get

  m7400/       /* m7400 with implied maltivec; mabi=altivec appended */
  m7400/novec  /* m7400, mno-altivec; mabi=altivec appended          */

However, if I add more CPUs and thus cannot use EXTRA_OPTS for 
mabi=altivec, by adding it to _OPTIONS and _DIRNAMES and applying
proper filtering the libs end up under

  m7400/vecabi
  m7400/vecabi/novec

can get a bit annoying if yet more options were to be added to
m7400 only...

> 
> It's basically the same as soft-floats are implemented in t-rtems (some
> cpus have both soft-float/fpu variants, some cpus have fpu variants only
> (imply hard-float), some variants have soft-float only (imply
> soft-float).
> 
> Finally, for some reasons I never understood, powerpc-rtems-gcc has
> -mno-eabi in its MULTILIB_EXTRA_OPTS, which I am not sure whether it
> interferes with -mabi=*.

It does not. -meabi selects the EABI and -mno-eabi the default (?) ie,
SYSV abi. -mabi=altivec (info gcc) adds altivec extensions to the 
current ABI. This is especially important if someone were to use -meabi
because of the reduced stack alignment.

  -meabi -> 8byte stack algmnt, r2 may be used for sdata2&friends,
            __eabi called at init
  -meabi -mabi=altivec -> 16byte stack algmnt, r2 used, __eabi called
  -mno-eabi -> 16byte stack algmnt, r2 not used, __eabi not called
  -mno-eabi -mabi=altivec -> 16byte stack algmnt, no r2,
             altivec extensions (ATM I'm not aware of anything other than
             stack algmnt).

baseline: if you link altivec code against a library compiled with 
-meabi only, your stack can be screwed up.

OTOH, low-end/low-mem CPUs might be interested in a meabi variant
due to the looser stack alignment req and extended short data areas
(gain in speed *and* footprint).

T.

> 
> Ralf
> 
> 
>