Re: [head tinderbox] failure on arm/arm

On Sun, Nov 12, 2006 at 05:07:11PM +0000, Nicholas Clark wrote:
> On Sun, Nov 12, 2006 at 09:28:49PM +0530, Joseph Koshy wrote:
> 
> > GCC/arm also thinks that the alignment requirement for
> > `char a[1]' is `4', even though `sizeof(char a[1])`
> > remains at 1.
> > 
> > This doesn't make sense at many levels.
> 
> But is legal for an ANSI C compiler to do so.
> (As I understand it, the reason for the original ARM ABI on other operating
> systems choosing to do this alignment was because it was thought that word
> alignment even of arrays would generate faster code. I think that they now
> realise that actually this is not the case)
> 
> I'm not following FreeBSD closely enough to know whether ARM has shipped as
> a released supported platform yet, but if not then I believe that FreeBSD
> is free to change its ARM ABI to anything that it feels more suitable.
> 
> It may be worth talking to the ARM Linux folks to find out what they would
> have done differently in the ABI had they known. I suspect that the EABI
> described in http://wiki.debian.org/ArmEabiPort is based on previous pain.
> 
> Has FreeBSD adopted the wonderful mixed endian IEEE 64 bit representation too?
> (Yep, that's legal. But catches a lot of code too)
> 
> Nicholas Clark

It was my choice to align structures on a word boundary, because of what you
pointed, and because of that little comment in gcc/config/arm/netbsd-elf.h :
2. A potential performance penalty may exist if strings are no longer
      word aligned.  GCC will not be able to use word load/stores to copy
      short strings.

I may just not have given enough though to the issue, if the EABI folks chose
to switch from word-aligned to no restriction, they certainly have their
reasons.
I consider we can still do the switch if we should, it will force people to
rebuild all their arm apps, but for now as far as I know all users of
FreeBSD/arm are FreeBSD developers, so a heads up should be enough. It has to
be done now, however.

No, we're not using the mixed endian IEEE 64bits representation. We're
defaulting to softfloat VFP. What would be te point of switching ?

Cheers,

Olivier