This is the mail archive of the binutils@sourceware.org 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


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


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