http://sourceware.org/bugzilla/show_bug.cgi?id=15222
Bug #: 15222
Summary: Alignment of load address of data sections containing
aligned data
Product: binutils
Version: 2.24 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: abgt.crt...@gmail.com
Classification: Unclassified
Created attachment 6916
--> http://sourceware.org/bugzilla/attachment.cgi?id=6916
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 chan
ge
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 programm
ing
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). Inclu
ded
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 = .
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
