This is the mail archive of the
mailing list for the binutils project.
Re: ALIGN directive showing different behavior than documented
- From: Sandra Loosemore <sandra at codesourcery dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 3 Aug 2015 13:53:11 -0600
- Subject: Re: ALIGN directive showing different behavior than documented
- Authentication-results: sourceware.org; auth=none
- References: <55BBE88A dot 5080802 at codesourcery dot com> <55BE97C6 dot 6050408 at codesourcery dot com> <20150803051936 dot GW26017 at bubble dot grove dot modra dot org>
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.