[Bug 195] powerpc: ABI confusion

[bugzilla-daemon at rtems.org]

http://www.rtems.org/bugzilla/show_bug.cgi?id=195





--- Comment #5 from strauman at slac.stanford.edu  2008-01-10 15:50:47 ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > Fix:
> > > Clarify the ABI situation.
> > > 
> > > From Thomas Doerfler:
> > > EABI and SVR4 are sufficently similar to accept the setting "no-eabi" for multilib generation. Only data type "long double" inside structures at non-16-byte-aligned positions might lead to trouble.
> > 
> > From Till Straumann:
> > Stack alignment is also different; EABI requires 8-bytes, SVR4 16-bytes.
> > RTEMS currently aligns the stack only to 8-bytes (since EABI is the default).
> > This is in violation of SVR4 but largely goes unnoticed (but it breaks
> > e.g., altivec which needs 16-byte stack alignment. Altivec is AFAIK compatible
> > with svr4 but not eabi).
> > 
> 
> Making the stack 16-byte aligned is OK if that helps.  
> 

The fact that we currently implement (parts of) EABI is reflected
by:

 1 on board init, we call __eabi() [only needed for initialization of
   R2/R13; we avoid execution of __init by means of special start-file
   rtems_crti.o]
 2 stack of all tasks is 8-byte aligned (interrupt/exception frames
   seem to always be multiples of 16-bytes).
 3 when creating a new task, r2, r13 are both copied from currently
   executing task

Note that 1) is in low-level assembly code and does currently not
check the PPC_ABI symbol.

IMO there are two possiblities:
 a) make rtems strictly svr4; eliminate 1 (but another mechanism would
    then be needed to initialize R13=_SDA_BASE_)
 b) leave the EABI default but align the task stack always to 16-bytes.
    IMO, this would be compatible with both, svr4 and eabi


-- 
Configure bugmail: http://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.