This is the mail archive of the
binutils@sourceware.org
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: Fri, 31 Jul 2015 15:28:42 -0600
- Subject: Re: ALIGN directive showing different behavior than documented
- Authentication-results: sourceware.org; auth=none
Alan Modra wrote:
Right, lhs.value is evaluated from fold_name case NAME here:
else if (tree->name.name[0] == '.' && tree->name.name[1] == 0)
new_rel_from_abs (expld.dot);
So the difference is that the unary operator is missing a conversion
from absolute to relative. I think that is a bug since we say the
value of dot inside a section is relative to the start of the section.
I wonder how many scripts rely on the old behaviour? If I don't hear
any objections to this change, I'll install the following in a day or
two.
* ldexp.c (align_dot_val): New function.
(fold_unary <ALIGN_K, NEXT>): Use it.
It turns out that this patch is causing problems for some linker scripts
Mentor distributes. I don't know if it's the change to ALIGN that is
doing it, or if it's exposing another bug somewhere else. :-S
The linker script includes bits like:
SECTIONS
{
...
.cs3.internalram : ALIGN (8)
{
__cs3_region_start_internalram = .;
*(.cs3.region-head.internalram)
*(.internalram)
. = ALIGN (8);
} >internalram AT>rom
.cs3.internalram.bss :
{
*(.internalram.b .bss.internalram)
. = ALIGN (8);
} >internalram AT>rom
__cs3_region_init_size_internalram = LOADADDR (.cs3.internalram.bss)
- LOADADDR (.cs3.internalram);
...
}
For the test program, nothing is being allocated to these sections.
Without the patch, the map file shows:
.cs3.internalram
0x1ffc0000 0x0 load address 0xa00003b8
0x1ffc0000
__cs3_region_start_internalram = .
*(.cs3.region-head.internalram)
*(.internalram)
0x1ffc0000 . = ALIGN (0x8)
.cs3.internalram.bss
0x1ffc0000 0x0 load address 0xa00003b8
*(.internalram.b .bss.internalram)
0x1ffc0000 . = ALIGN (0x8)
0x00000000
__cs3_region_init_size_internalram = (LOADADDR (.cs3.internalram.bss) -
LOADADDR (.cs3.internalram))
And with the patch, we get:
.cs3.internalram
0x1ffc0000 0x0 load address 0xa00003c0
0x1ffc0000
__cs3_region_start_internalram = .
*(.cs3.region-head.internalram)
*(.internalram)
0x1ffc0000 . = ALIGN (0x8)
.cs3.internalram.bss
0x1ffc0000 0x0 load address 0xa00003bc
*(.internalram.b .bss.internalram)
0x1ffc0000 . = ALIGN (0x8)
0xfffffffc
__cs3_region_init_size_internalram = (LOADADDR (.cs3.internalram.bss) -
LOADADDR (.cs3.internalram))
Note that the LMA assigned to .cs3.internalram.bss is now less than that
of the previous section as well as not aligned. So
__cs3_region_init_size_internalram ends up as a negative number which is
confusing the heck out of startup code that wants to copy the
initialized data from its LMA in rom to its VMA in internalram.
Any ideas for fixing this short of reverting the patch?
-Sandra