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

[Bruce Evans]

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:

X Wed Apr 26 15:54:10 1995  Ken Raeburn  <raeburn at cujo.cygnus.com>
X 
X 	Support for more portable alignment handling in assembly code,
X 	based on patches from Bryan Ford <baford at schirf.cs.utah.edu>:
X 	* read.c (potable): Added balign and p2align, for aligning by
X 	bytes or powers of two independent of what ".align" does for a
X 	given target.
X 	* doc/as.texinfo: Document them.

Everything should have, and still should, use .p2align for portability
and anti-confusion.

FreeBSD on x86 didn't catch up with this change until 1997.  The fix is
disguised in some ELF changes in <machine/asmacros.h> rev.1.16.  It is
also a style bug to hard-code .align statements.  x86 is missing this
style bug, so only about 3 lines in this file needed to be changed to
keep up with the change in gas.  I couldn't find when gas changed the
default, and suspect that it was conditional on ELF.

Other arches never supported aout, but they apparently ended up with the
confusing aout semantics for .align.  .align is apparently portable now,
but it is still too confusing to use.

This is especially confusing for small powers of 2

A few related style bugs have crept into x86/*.s:
- i386 has 2 hard-coded .aligns for kdtrace
- amd64 and i386 have a few hard-coded .p2align's.  Half are my fault.
   There is a SUPERALIGN_TEXT macro, but no SUPERALIGN_DATA macro.

The [SUPER]ALIGN_TEXT and ALIGN_DATA macros are a bit too simple.  They
hide complications for profiling.  However, the best alignment is very
machine-dependent and context-dependent.  Modern compilers generate
very different amounts of alignment depending on -march and the context
(different for function targets than for other branch targets...).
The macros should at least depend on -march.  SUPERALIGN_TEXT is just a
hard-coding of a special context for -march=i486.

Bruce