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: Large lma delta using binutils 2.19


On Tue, Mar 2, 2010 at 8:48 AM, James Blackburn
<james.blackburn@broadcom.com> wrote:
> Hi All,
>
> I've been moving from binutils 2.17 to 2.19 and noticed an oddity in the
> final lma / vma address allocation.
>
> In ld_lang.c#lang_size_sections_1(...) (line 4705 on HEAD) the lma is set to
> dot + (last.lma - last.vma). The result is that a subsequent section gets a
> very large lma.
>
> Is this the intended behaviour? If so what's the recommended way of getting
> the linker to behave in the previous way and use the calculated vma(/dot) as
> the lma?
>
> Many thanks,
> James
>
> ld script:
>
> SECTIONS
> {
> ?.text 0x00000000: { *(prologue epilogue) }
> ?.text_00002000 0x00002000: { *(.text_00002000) }
> ?.text_02003f48 0x00003f48: { *(.text_02003f48) }
> ?.data_40017fe0 0x40017fe0: { *(.data_40017fe0) }
> ?FNSC_INIT = 0x40000000;
> ?.fnsc_init 0x00003f58: AT(ABSOLUTE(FNSC_INIT)) { *(.fnsc_init) }
> ?REG_INIT = 0x40000888;
> ?.reg_init ABSOLUTE(REG_INIT): { *(.reg_init) }
> }
>
> Previously:
> readelf -l
>
> Program Headers:
> ?Type ? ? ? ? ? Offset ? VirtAddr ? PhysAddr ? FileSiz MemSiz ?Flg Align
> ?LOAD ? ? ? ? ? 0x0000f8 0x00000000 0x00000000 0x01200 0x01200 R E 0x1
> ?LOAD ? ? ? ? ? 0x0012f8 0x00002000 0x00002000 0x01f48 0x01f48 R E 0x1
> ?LOAD ? ? ? ? ? 0x003240 0x02003f48 0x00003f48 0x00010 0x00010 R E 0x1
> ?LOAD ? ? ? ? ? 0x003250 0x02003f58 0x40000000 0x00888 0x00888 R E 0x1
> ?LOAD ? ? ? ? ? 0x003ad8 0x40000888 0x40000888 0x006e0 0x006e0 R ? 0x1
> ?LOAD ? ? ? ? ? 0x0041b8 0x40017fe0 0x40017fe0 0x00060 0x00060 R ? 0x1
>
> ?Section to Segment mapping:
> ?Segment Sections...
> ? 00 ? ? .text
> ? 01 ? ? .text_00002000
> ? 02 ? ? .text_02003f48
> ? 03 ? ? .fnsc_init
> ? 04 ? ? .reg_init
> ? 05 ? ? .data_40017fe0
>
> 2.19+:
> readelf -l
>
> Program Headers:
> ?Type ? ? ? ? ? Offset ? VirtAddr ? PhysAddr ? FileSiz MemSiz ?Flg Align
> ?LOAD ? ? ? ? ? 0x0000f8 0x00000000 0x00000000 0x01200 0x01200 R E 0x1
> ?LOAD ? ? ? ? ? 0x0012f8 0x00002000 0x00002000 0x01f48 0x01f48 R E 0x1
> ?LOAD ? ? ? ? ? 0x003240 0x02003f48 0x00003f48 0x00010 0x00010 R E 0x1
> ?LOAD ? ? ? ? ? 0x003250 0x02003f58 0x40000000 0x00888 0x00888 R E 0x1
> ?LOAD ? ? ? ? ? 0x003ad8 0x40017fe0 0x40017fe0 0x00060 0x00060 R ? 0x1
> ?LOAD ? ? ? ? ? 0x003b38 0x40000888 0x7fffc930 0x006e0 0x006e0 R ? 0x1
> <=== Large PhysAddr
>
> ?Section to Segment mapping:
> ?Segment Sections...
> ? 00 ? ? .text
> ? 01 ? ? .text_00002000
> ? 02 ? ? .text_02003f48
> ? 03 ? ? .fnsc_init
> ? 04 ? ? .data_40017fe0
> ? 05 ? ? .reg_init
>
>

From my Linux binutils release note:

---
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.

For

.data.init_task : { *(.data.init_task) }

LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use

.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }

to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior.  You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers.
---

I don't know if it is the same issue.


-- 
H.J.


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