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
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
