> On Mon, 18 Mar 2002, Richard Earnshaw wrote:
> 
> > So, the 1.6 branch should be happening soon, and we aren't quite ready for
> > the switch to ELF yet.  I'm aware of the following issues.
> >
> > 1) Structure returning.  We currently don't conform to the ATPCS
> > conventions for this (currently using old, horrible, APCS conventions).
> > (rearnsha)
> 
> I think this is an insignificant problem, in that (I hope) structure
> returning is a very rare activity, so we can get away with claiming the
> old behaviour to be a bug in GCC and fixing it when we can.  It's not as
> if GCC isn't short of other bugs.

It's true that the fix for this shouldn't be too hard, but it is an 
understatement of the potential impact of the issue.

> > 2) Enums.  Have all the code changes been made? (bjh21)
> 
> There are two areas left:  One's a tiny patch to Heimdal that I forgot,
> and I'll send off tonight.  The other's a few fixes to DHCP, which are
> present in the upstream sources but that we haven't imported.  My
> intention is to pull down the relevant changes tonight.
> 
> > 3) Conformance.  We have no measure of how well our code conforms to the
> > EABI.
> >
> > In addition to these there is the major issue that the EABI to which we
> > want to conform is still not finalized, making it very difficult for us to
> > have any confidence that we be in conformance to the ABI when we can't say
> > for certain what it will eventually be.
> 
> This was always going to be a problem, but I don't think we can wait
> forever just because ARM can't get their act together.

Maybe, but if we aren't conformant in all respects then most of the point 
of doing this exercise of adopting the ARM ABI has been a waste of time, 
since we loose the capability to bring in pre-compiled objects or use 
tools other than gcc for compiling.  Nobody is going to be interested in 
trying to support a platform that is *nearly* conformant with the ABI.

> >  For example, it has recently been
> > suggested that we should nail a register for thread local storage (as
> > several other processors do).  No decision has yet been reached on this
> > issue, and even if we do adopt one, it is unclear whether it should be r9
> > or r10.
> 
> Shouldn't marking -ffixed-r9 -ffixed-r10 deal with this in a
> forward-compatible way?

Well that would be safe, but it has consequences, and I'm not talking 
about the loss of performance due to losing two registers (we would get at 
least one of those back eventually).  The main problem is that r10 is 
currently what gcc uses as its PIC register, and r9 is the fall-back if 
r10 is used for other things.  We would have to have yet another hack in 
the compiler to handle this.  Even that isn't the major problem:  Some of 
the ASM code for the ARM libraries uses this register for PIC support.  
That code would have to found and altered to use a different register if 
it is not a leaf function.

> 
> > Finally, I noticed the following on the GCC web pages the other day
> > concerning gcc-3:
> >
> >   Enumerations are now properly promoted to int in function parameters
> >   and function returns. Normally this change is not visible, but when
> >   using -fshort-enums this is an ABI change.
> >
> > I'm not sure what, if any, impact this might have on ARM code (which
> > normally promotes small objects to int anyway), but I'd be nervous about
> > using gcc-2.95 if this might cause an incompatible change (unless we can
> > identify the change and incorporate it).
> 
> I can't see that this will make a difference on ARM.

Without knowing precisely what has changed, I'm not sure how you can be so 
confident about this.

> > So, given all of the above, I have to say that my gut feeling is that it
> > would be premature for arm switch to ELF at this time, in particular to
> > try and rush things before the 1.6 release branch is made: it would be
> > much better to do one more aout system and then make sure we were truly
> > ready for the next release.
> 
> Note that this will make arm26, evbarm and netwinder unreleasable.  It was
> certainly proposed that _all_ platforms released in 1.6 should be able to
> use the new toolchain, which for ARM means ELF, but that proposal may have
> died.

arm26 is a problem yes.  For the others, it would mean that the kernel 
couldn't be built with the normal compiler.  However, there is no reason 
why either evbarm or netwinder can't run with an aout userland -- I've 
done it myself on evbarm.

R.