Re: ALIGN directive showing different behavior than documented

[Sandra Loosemore <sandra at codesourcery dot com>]

On 08/02/2015 11:19 PM, Alan Modra wrote:

> 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.

Using an ALIGN expression with an alignment greater than that of its 
enclosing section is absolutely not undocumented behavior.  Both the 
current ld manual and the one from 1993 include such an example.

> 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.

I understand that the behavior of unary ALIGN is something of an 
anomaly, but changing it now seems likely to cause obscure breakage and 
backward compatibility problems.  If the problem your patch was trying 
to solve was a discrepancy between the documentation and the 
implementation, it seems more user-friendly just to fix the 
documentation rather than pile even more warts on the implementation of 
ALIGN.  E.g. something like replacing the current parenthetical remark 
about the equivalence of the two forms with a new paragraph:

"For historical compatibility reasons, the unary ALIGN operator aligns 
the absolute address of the location counter (.) rather than its 
section-relative offset.  On the other hand, when given a 
section-relative address as its first argument, the binary form aligns 
its offset.  ALIGN(align) is therefore only equivalent to ALIGN(., 
align) outside of a section definition."

???

OTOH, if the consensus is that the linker script is bad and specifying 
an alignment within the section that is greater than the section 
alignment is an error, I think it would be much better for the linker to 
issue a diagnostic for this rather than to silently fail to perform the 
indicated alignment (that it used to do properly) and/or do other things 
like get confused and start allocating section addresses that go 
backwards.  And, remove the example in the manual, of course.

-Sandra