Created attachment 6916 [details]
Test case

I'm encountering problems with recent versions of LD, which appear to be the result of the change in behaviour implemented through…

http://sourceware.org/ml/binutils/2010-12/msg00004.html

Unfortunately although this change may be suitable for use on Linux systems where the image is being loaded directly to its execution address, the change as implemented does not take into account that on many other systems it may be completely valid for the LMA and VMA of the data section to have different alignment.


Detail
######

I've recently moved from a toolchain based on GCC 4.5.1 with ld 2.20 to the "GNU Tools for ARM Embedded Processors" (gcc 4.7.3 with ld 2.22) and am now encountering problems with alignment of .data, which is causing both an increase in image load size (ie flash consumption, which can be critical on small footprint parts), and also in some circumstances issues with programming images into flash.

Data items are often aligned in Embedded systems (for example because they may be being used as buffers accessed directly by hardware peripherals).


For example, you might have something like:

int x __attribute__ ((aligned (128))) = 42;

Normally when linking an application, the load address of the data section (ie its initial contents in Flash - LMA) will follow on directly from the end of the code (ie .text).

I would expect the same to continue to happen when the data section contains aligned globals such as the above - as it is the execution address (ie VMA) of the global that needs to be aligned. 

I've produced a simple example which shows up the problem (attached). Included in this is a linker script that places the data appropriately in the flash and RAM on my system thus:

	.data : ALIGN(4)
	{
		FILL(0xff)
		_data = .;
		*(vtable)
		*(.data*)
		. = ALIGN(4) ;
		_edata = .;
	} > RamLoc32 AT>MFlash512

When the test case is built using  LD 2.20 I get the expected behaviour:


LD 2.20
=======
         0x00000290 __exidx_end = .
         0x00000290 _etext = .

.data 0x10000000 0x100 load address 0x00000290 <---
FILL mask 0xff
         0x10000000 _data = .
*(vtable)
*(.data*)
.data 0x10000000 0x0 startup.o
.data 0x10000000 0x100 main.o
         0x10000000 y
         0x10000080 x
         0x10000100 . = ALIGN (0x4)
         0x10000100 _edata = .


However it is not the case with LD 2.21/2.22. Here the linker applies the alignment to the load address as well, causing the problem padding to be introduced :


LD 2.22
=======
         0x00000290 __exidx_end = .
         0x00000290 _etext = .

.data 0x10000000 0x100 load address 0x00000300 <---
FILL mask 0xff
         0x10000000 _data = .
*(vtable)
*(.data*)
.data 0x10000000 0x0 startup.o
.data 0x10000000 0x100 main.o
         0x10000000 y
         0x10000080 x
         0x10000100 . = ALIGN (0x4)
         0x10000100 _edata = .