Subject: Re: ARM: The switch to ELF. Are we ready yet?
To: None <Richard.Earnshaw@arm.com>
From: Jason R Thorpe <firstname.lastname@example.org>
Date: 03/18/2002 12:08:17
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).
Isn't the infrastructure in GCC such that this is pretty easy to fix?
> 2) Enums. Have all the code changes been made? (bjh21)
> 3) Conformance. We have no measure of how well our code conforms to the
What particular concerns wrt EABI conformance do you have?
> 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?
> 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.
> 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.
-- Jason R. Thorpe <email@example.com>