Bug 15222 - Alignment of load address of data sections containing aligned data
Summary: Alignment of load address of data sections containing aligned data
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.24
: P2 normal
Target Milestone: ---
Assignee: Alan Modra
Depends on:
Reported: 2013-03-04 11:54 UTC by abgt.crtpub
Modified: 2013-03-05 03:15 UTC (History)
1 user (show)

See Also:
Last reconfirmed:

Test case (4.84 KB, application/zip)
2013-03-04 11:54 UTC, abgt.crtpub
fix currently under test (424 bytes, patch)
2013-03-04 12:56 UTC, Alan Modra
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description abgt.crtpub 2013-03-04 11:54:03 UTC
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…


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.


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)
		_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 = .
.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 = .
.data 0x10000000 0x0 startup.o
.data 0x10000000 0x100 main.o
         0x10000000 y
         0x10000080 x
         0x10000100 . = ALIGN (0x4)
         0x10000100 _edata = .
Comment 1 Alan Modra 2013-03-04 12:56:21 UTC
Created attachment 6917 [details]
fix currently under test
Comment 3 cvs-commit@gcc.gnu.org 2013-03-05 03:11:36 UTC
CVSROOT:	/cvs/src
Module name:	src
Branch: 	binutils-2_23-branch
Changes by:	amodra@sourceware.org	2013-03-05 03:11:31

Modified files:
	ld             : ChangeLog ldlang.c 
	ld/testsuite   : ChangeLog 
Added files:
	ld/testsuite/ld-scripts: rgn-at6.d rgn-at6.s rgn-at6.t rgn-at7.d 

Log message:
	PR ld/15222
	* ldlang.c (lang_size_sections_1): When given an lma_region align
	LMA as per VMA only if lma_region is the same as region.
	* ld-scripts/rgn-at6.s, * ld-scripts/rgn-at6.t, * ld-scripts/rgn-at6.d,
	* ld-scripts/rgn-at7.t, * ld-scripts/rgn-at7.d: New tests.

Comment 4 Alan Modra 2013-03-05 03:15:29 UTC
Fixed mainline and 2.23 branch