Re: multilib question

[Till Straumann <strauman at slac dot stanford dot edu>]

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