[Bug ld/15222] New: Alignment of load address of data sections containing aligned data

[abgt.crtpub at gmail dot com]

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: address@hidden

        ReportedBy: address@hidden

    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.