Subject: Re: ELF
To: Richard Earnshaw <rearnsha@arm.com>
From: David Brownlee <abs@netbsd.org>
List: port-arm32
Date: 11/07/2000 16:49:18
On Thu, 2 Nov 2000, Richard Earnshaw wrote:

> 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.
>
	Both seem very reasonable.

> 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).
>
	Are there any plans for other projects to work on this in gcc?

> 4) We should use the DWARF-based exception throwing mechanism -- this is
> more efficient.
>
	What is the future direction for gcc on this?

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

	That gives us three FP formats: FPA, VFP, and softfloat, or does
	softfloat use the FPA format?

	How expensive is it to convert between the various formats?
	Can we transition softfloat to use the VFP format at the switch
	to ELF, then provide a softfloat libm, a VFP libm, and a 'convert
	format to FPA, perform operation, convert result back' libm,
	selectable via a sysctl a'la NetBSD/i386?

                David/absolute
			       -- www.netbsd.org: A pmap for every occasion --