Re: ALIGN directive showing different behavior than documented

[Alan Modra <amodra at gmail dot com>]

On Sun, Aug 02, 2015 at 04:20:54PM -0600, Sandra Loosemore wrote:
> and documents it thusly:
> 
> @item ALIGN(@var{exp})
> @kindex ALIGN(@var{exp})
> @cindex rounding up location counter
> Return the result of the current location counter (@code{.}) aligned to
> the next @var{exp} boundary.  @var{exp} must be an expression whose
> value is a power of two.  This is equivalent to
> @example
> (. + @var{exp} - 1) & ~(@var{exp} - 1)
> @end example

If you test the behaviour of ALIGN, you'll find that it now matches
the above description.  The patch that you want to revert not only
made the binary and unary ALIGNs behave the same, but also made ld.bfd
behave the same as ld.gold, and made
  . = ALIGN (8);
behave the same as
  . = (. + 8 - 1) & ~(8 - 1);

"." inside an output section statement is relative to the start of
the section.  ld.bfd unary ALIGN was alone in treating its implicit
"." as absolute.

So there is quite a good case for fixing unary ALIGN, and the
documentation you quote actually strengthens the case..

Against that, you've found some questionable linker scripts that now
misbehave.  I'm saying they are questionable because ". = ALIGN (8);"
inside a section that is only "ALIGN (4)" is at the heart of the
problem, and I reckon the linker scripts you have are newer than the
description of ALIGN that you quote above.  ie. The scripts are
relying on undocumented behaviour.

I'm not trying to discount the fact that the previous behaviour "was
in place for 20+ years" as you put it, and the change breaks at least
some existing scripts.  It might be possible to reduce the impact of
this change, for example, by making ". = ALIGN (k);" affect the
alignment of an output section in the same way alignment of an input
section affects alignment of an output section.

-- 
Alan Modra
Australia Development Lab, IBM