> On Mon, Mar 18, 2002 at 05:45:45PM +0000, Richard Earnshaw wrote:
> 
>  > 1) Structure returning.  We currently don't conform to the ATPCS 
>  > conventions for this (currently using old, horrible, APCS conventions).  
>  > (rearnsha)
> 
> Isn't the infrastructure in GCC such that this is pretty easy to fix?

Yes, this is fixable.  Just haven't had time to do it yet (I've only got 
about 5 different variants of gcc/arm that I'm working on...)

>  > 3) Conformance.  We have no measure of how well our code conforms to the 
>  > EABI.
> 
> What particular concerns wrt EABI conformance do you have?

My concern is that we don't have any tests for conformance, so we can't 
say whether we conform or not.

> 
>  > 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.  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.
> 
> Hm.  Sigh, this sucks.
> 
> Perhaps we should mark our binaries as OSABI_NETBSD?

Well, for the executables we should be doing that anyway (since they will 
rely on NetBSD system calls and shared-library support and the like).  For 
linkable objects it misses the point.

> 
>  > 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).
> 
> Yuck, we should definitely fix this.

Well, first we must establish that there is a problem; but the real 
difficulty might be determining which bit of the compiler has actually 
changed.  Several parts of the gcc were extensively rewritten for gcc-3.

>  > 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.
> 
> Except there are platforms that we'd like to include in the release, but
> which cannot be built practically with the a.out toolchain (e.g. evbarm).
> It would be a real shame to release these as ELF and then flag-day them
> after the release.

It's not a situation I'm entirely happy with either, but I'd rather get it 
right than have to deal with the pain if we screw up.  AFAICT there's no 
reason why evbarm can't run an aout userland.  I've certainly done it on 
the evbarm/integrator port.

R.