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.

> 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.

>  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?

> 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.

> 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.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>