strauman at slac.stanford.edu
Thu Nov 10 18:07:33 UTC 2005
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=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
> * 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
can get a bit annoying if yet more options were to be added to
> 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
> 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
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).
More information about the users