svn commit: r276596 - in head/sys/arm: arm include

[Ian Lepore]

On Sat, 2015-01-03 at 19:34 +1100, Bruce Evans wrote:
> On Fri, 2 Jan 2015, Ian Lepore wrote:
> 
> > Log:
> >  Fix alignment directives in arm asm code after clang 3.5 import.
> >
> >  The ancient gas we've been using interprets .align 0 as align to the
> >  minimum required alignment for the current section.  Clang's integrated
> >  assembler interprets it as align to a byte boundary.  Fortunately both
> >  assemblers interpret a non-zero value as align to 2^N so just make sure
> >  we have appropriate non-zero values everywhere.
> 
> > Modified: head/sys/arm/arm/bcopyinout.S
> > ==============================================================================
> > --- head/sys/arm/arm/bcopyinout.S	Fri Jan  2 23:27:16 2015	(r276595)
> > +++ head/sys/arm/arm/bcopyinout.S	Fri Jan  2 23:46:26 2015	(r276596)
> > @@ -52,7 +52,7 @@ __FBSDID("$FreeBSD$");
> > #else
> >
> > 	.text
> > -	.align	0
> > +	.align	2
> 
> This is still confusing.
> 
> Doesn't clang on arm support .p2align?  On x86, '.align N' means align to
> boundary N, where N must be a power of 2.  Alignment to boundary 2**N
> can be done by expanding 2**N literally or using '.p2align N'.  The latter
> is better, and is always (?) used in FreeBSD sources.  It was also
> generated by gcc-3.3.3.  gcc-4 broke this and generates .align, and clang
> is bug for bug compatible with the newer gcc.
> 
> .align used to mean power of 2 alignment on x86 too, but gas changed this
> in 1995, or at least introduced .p2align then:

When I was searching for info on this yesterday what I found was some
old mail threads in various toolchain developer venues in which it was
mentioned that x86 is the odd one for .align taking a byte count that
must be a power of 2 and all other platforms have always had the 2**N
interpretation.

I also think arm was odd in its interpretation of .align 0; other
platforms interpret it as byte-alignment.  It leaves arm with no way to
change from an alignment of >1 to 1, so this reinterpretation by the
clang authors, while a bit inconvenient for old code, seems sensible.

I was also thinking that maybe a good solution to this would be
ALIGN_TEXT and ALIGN_DATA macros to consolidate the yuck into one place,
but that's a project for another day, yesterday I just wanted to get the
arm world working again.  Before I start adding new macros I really want
to investigate the possibilty of using real asm macros instead of CPP,
if I can find a useful intersection of syntaxes between the various
tools we have to use.

-- Ian