ppc multlibs and BSP removal was Re: powerpc altivec support

[Joel Sherrill <joel@OARcorp.com>]

Sergei Organov wrote:
> "Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
> 
> 
>>Sergei Organov wrote:
>>
>>>Ralf Corsepius <ralf.corsepius at rtems.org> writes:
>>>[...]
>>
>>>>Well, as I understand it from digging in GCC's and RTEMS sources,
>>>>powerpc-rtems-gcc defaults to "sysv-eabi" (whatever this is).
>>>>
>>>>All I can say is:
>>>>
>>>>* we are using -mcall-sysv. AFAIU, this means we are using SYSV calling
>>>>conventions.
>>
>>>>* The default stack boundary (This is the term GCC uses) is 8.
>>>>
>>>>* -mno-eabi switches the stack boundary to 16.
>>>>
>>>>* Explicitly passing -meabi doesn't seem to have any effect on the stack
>>>>boundary. Therefore, I conclude the implicit default is -meabi.
>>>>
>>>>* ATM, the multilibs are being built *explicitly* using -mno-eabi,
>>>>i.e. newlib and GCC's libs are being built with a stack boundary of 16.
>>>>According to a comment in rs6000.c, this implies they are EABI and SYSV
>>>>compatible.
>>>
>>>Except that for RTEMS building all the libraries with -meabi does
>>
>>>make sense as it decreases resulting executable size (and slightly
>>>increases speed).
>>>
>>
>>>>* There doesn't seem to be a preprocessor define denoting if using EABI
>>>>or SYSV.
>>>>
>>>>So - what are we using? I don't know.
>>>>
>>>>AFAIU, we are using SYSV for newlib/GCC (-mno-eabi -mcall-sysv) and a
>>>>corrupted multilib'ed cpukit (-mno-eabi -mcall-sysv -DPPC_ABI_EABI).
>>>
>>>Except that PPC_ABI_EABI seems to have exactly the same effect on the
>>
>>>code as PPC_ABI_SYSV except that in the former case thread context's r2
>>>is initialized with current r2 that can't break SYSV. So "corrupted"
>>>doesn't in fact apply.
>>>Strange thing is that CPU_MINIMUM_STACK_FRAME_SIZE is defined to 8 no
>>
>>>matter if SYSV or EABI is defined. And that's the case for both old and
>>>new exception processing. Should be 16 for SYSV, I think. I myself
>>>always use EABI (-meabi -msdata=eabi), so this bug doesn't affect my
>>>code, -- don't know about those who use SYSV.
>>
>>If these are the only two differences, is it possible to just use the tigher
>>stack alignment and always initialize r2 for EABI?  Then they would be the
>>same from RTEMS multilib perspective.
> 
> 
> I believe that it's safe to always initialize initial thread r2 with
> current r2. Except that when SYSV is used it will result in random r2
> value (inherited from thread creating this one) when thread starts, --
> don't know if that is significant for somebody (e.g., could be essential
> for debugging when one wishes to initialize all the registers with some
> template).

On all ports, RTEMS only initializes a very small set of registers
when a thread's context is initialized, so if it doesn't do harm,
this would be OK.

Sounds safe enough to me.

>>What else varies in RTEMS based upon the two APIs?
> 
> 
> I don't see anything else, but I do believe CPU_MINIMUM_STACK_FRAME_SIZE
> should be either 16 for both, or, alternatively, should be 16 for SYSV
> and 8 for EABI. I don't think current value 8 is safe for SYSV.
> 

We should make the alignment meet the strictest requirement and move
along.  16 byte stack alignment is going to help performance on most
CPUs anyway.  And those it doesn't help are not going to suffer.

--joel