Obsoleting elfarm-oabi [was Re: PATCH: Reduce size of SymbianOS DLLs]

[Richard Earnshaw <rearnsha@gcc.gnu.org>]

On Tue, 2004-11-02 at 16:42, Mark Mitchell wrote:
> OK.  In that case, I'd say we could just remove the code, then.  What's 
> the point in pretending we might keep it, if we've already made up our 
> minds?

Let's try and bring this to a rational conclusion.

We have three possible courses of action

1.  Obsolete elfarm-oabi.c, but change nothing for now

2.  Obsolete elfarm-oabi.c and split the code common with the current
ABI into separate files.

3.  Skip obsoleting elfarm-oabi.c and proceed straight to deletion.

I've done some archaeology, and it turns out that the old abi was named
so in February 1999, ie 5+ years ago.  That appears to correspond with
the binutils 2.10 release (we're now at 2.15).  The old ABI was only
ever added as a stop-gap because at the time it was first created ARM
hadn't published an ELF specification for ARM.

Daniel asserts that it isn't really possible to test the oabi code
because the assembler always defaults to the 'new' ABI (even in the oabi
configuration :-) ; this implies that there are almost certainly bugs
(untested code is almost always buggy or bit-rotten in my experience).

A final note is that there is no gcc configuration for the old abi, the
only way it would be even remotely possible to invoke it would be to
pass -Wa,-moabi to every possible invocation of the compiler.   I find
it hard to believe that has been happening for 5 years and yet that
nobody has proposed creating a configuration of gcc that does that by
default.

So my opinion is that we should go straight to option 3.  The 'risk' is
minimal, and if it does materialise we could push back by insisting
somebody else step forward to maintain that specific code if it is
resurrected: once it is separate from the current ARM code that is far
more feasible.

Nick, of course, has a veto; but he doesn't have to use it...

R.