> > This is a well known problem and the reason that arm32 hasn't switched
> > to egcs yet. IIRC softloat.c uses some bugs in gcc that egcs doesn't
> 
> It was only a bug if you required compatibility with the reference Acorn
> compiler. EGCS is choosing to be compatible, even though it means a small
> performance hit when returning 8-byte structs.

There was a bug in EGCS for netbsd/arm32 in that it switched to using 
reg-struct-return as a default instead of pcc-struct-return which was the 
case for gcc-2.7.2 -- there is a simple patch, which I have posted which 
sets pcc-struct-return as the default for this port.  Softfloat.c violated 
the netbsd/arm32 ABI and at the same time exploited a bug in gcc-2.7.2 to 
achieve a particular effect.  That bug was fixed in egcs, so softfloat.c 
no-longer compiles in the same way.

> 
> I just checked gdb-4.17 and the BFD in there doesn't know about the Acorn
> compiler's object format, just RISCiX and the usual American suspects:
> aout, coff, and (ugh) PECOFF.
> 
> So it's not particularly easy for us to actually _link_ with code produced
> by the Acorn compiler. That means nobody is really in danger of experiencing
> real problems, and transitioning our own ABI is a royal pain, so why do it?
> 
> About the only argument I can think of is that we may want easy integration
> with cross compilers that use the Acorn object format, but that would depend
> on upcoming work in egcs (of which I might simply be unaware).
> 

Compatibility with Acorn Object/Image Format (AOF/AIF) is, I agree, not a 
high priority, given that it is largely only available on RISC OS 
platforms.  However, ARM's own toolkit can now generate ELF executables, 
and will soon be able to generate ELF linkable objects.  IMO it would be 
good if we could migrate to being compatible with this at an appropriate 
time.

Reasons:

i)   ELF is already the standard format (as far as I can see) for most 
NetBSD platforms.

ii)  It has a much richer file format which makes certain linking tasks 
much more straight forward.  It also means things like C++ exceptions can 
be supported  with a much lower run-time overhead (at least in the g++ 
implementation).

iii) It supports a significantly more powerful debugging format (Dwarf) 
than a.out (stabs).

iv)  The linux/ARM guys are already using ELF -- though I think they are 
using a non-standard object format with it.  However, ELF is sufficiently 
rich that we could distinguish executables and DTRT with them.

v)   It should allow a path for interworking with Thumb code and the new 
ARM10 VFP format, something it would be very hard to squeeze into the 
existing a.out object format (we have just about used all the relocation 
types).


I would guess that it would also be possible to use the change to a new 
binary file format to allow us to fix some weaknesses in the ABI, since it 
should be possible to support existing (a.out binaries) via old shared 
libraries -- that is, an ELF binary would link an ELF shared library, and 
an a.out binary would link an a.out shared library (is it possible to make 
the kernel do this?).

However, if we go this way, we shouldn't do this in a rush: we should work 
out carefully what the problems are with the current ABI and try to fix 
them with a single new format (given that we can continue to support 
existing executables).  After all, we have something that works now and we 
want to be sure we will improve upon it with anything new.

Comments?

Richard.