> My understanding is that the netbsd arm32 a.out ABI has slightly
> different structure alignment/layout conventions than the standard ARM
> elf ABI, which means that moving to ELF on arm32 will require either
> (a) some really ugly compat code, or (b) a "flag day" when both kernel
> and all userland code have to be updated in lockstep.


Not true, but the time we move to ELF would be a good opportunity to have a
FLAG day, since ELF shared libs are never used with legacy a.out
executables.  This gives us a (relatively) clean sheet to fix some of the
oddities that the arm32 port has (but that arm26 managed to avoid).

I don't think anything that might be changing would affect the layout of 
information passing across the user/kernel interface, which is the only 
one that would need careful attention at the time of a move to ELF.

In the spirit of trying to move things forward, I'll note some (I can't be 
sure I've remembered all of them) of the things I think should be fixed 
below.

1) Structure alignment -- we should move to word-aligned structures, as 
the rest of the ARM world has.
2) Structure returning -- we should conform to the normal rules for 
structure return.

The following two are more open to debate, but I'll put them forward 
anyway.

3) We should consider adopting a more modern version of the ARM ABI (ie 
one of the ATPCS variants).  This would make support of Thumb code much 
easier.  Unfortunately, this is a major task, since at present GCC does 
not support these -- though there is no reason why the code can't be 
added).

4) We should use the DWARF-based exception throwing mechanism -- this is 
more efficient.

Finally, we need to put some more thought about what sort of Floating 
point support we want -- the latest ARM floating point architecture (VFP) 
is incompatible in both instruction format and data format with the 
existing FPA layout (don't ask me why, I wasn't privy to the decision).  
Maybe a change like this would be better considered as a completely new 
port.

Richard.