This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ALIGN directive showing different behavior than documented

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]