RFC: Removing OLD_EXCEPTIONS powerpc multilib variants

[Till Straumann]

Forgive me - I just don't understand - why you have to build
toolchain variants if all you want are different libcpu versions?

Why does the toolchain have to be built for the two exception models?
Just so the compiler picks different libcpu versions based on a
-DOLD_EXCEPTIONS or am I missing something here? Or to get it to
build two different versions using different flags?

The goal is distributing a toolchain that works for all BSPs.
Hence, you only need a (toolchain) variant if a BSP needs the standard
libraries to be built in a different way. soft-float is a candidate,
as is altivec or eabi but binary compatible CPUs or different CFLAGS
the stdlibs dont' depend on are NOT.

I'm not sure we need multilibs for RTEMS itself. Most people are
OK with building it themselves and need only one ore a few BSPs
and are probably happy without RTEMS multilibs.

Baseline: at some level you have to stop multilibbing because
           the number of variants grows exponentially - IMO the
           appropriate level is the toolchain. Once cpukit is
           totally BSP independent multilibbing can be extended
           there.

Till.

Ralf Corsepius wrote:
> On Wed, 2005-02-09 at 09:47 -0800, Till Straumann wrote:
> 
>>I don't understand the need for a toolchain variant
>>for the exception model in the first place -- what
>>different features does OLD_EXCEPTIONS trigger in
>>libgcc/newlib/... ??
> 
> As far as code generation is concerned: None.
> 
> What introduces this need is RTEMS's cpukit. It contains code which is
> conditionally compiled, based on pre-defined defines distinguishing
> between old- and new- exception processing.
> 
> Now, the problem is the sheer amount of defines being used by the
> powerpc port and identifying which of them are conditionally being used
> based on old-/new-exception processing.
> 
> It's simply as this: Oversight has gone lost.
> 
> 
>>I believe this to be pure bloat anyways.
> 
> In an ideal world - yes. Historically - no.
> 
> If you can prove that there is no code in cpu which is conditionally
> being compiled for old-exception/new-exception processing, these
> multilib variants can be removed.
> 
> In the past, this did not apply. Since then, a lot as changed, and I am
> close to be able to prove or counter-prove this - However, I am still
> not there.
> 
> 
>> It only would
>>matter if you intend to create RTEMS libcpu variants
>>- one for the old and one for the 'new' exception model.
> 
> Right, that's what I am aiming at - I have an experimental patch pending
> which ATM moves ca. 50% of all the powerpc defines from cpukit to
> libcpu.
> 
> Ralf
> 
>