[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multilib question
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).