[LLVMdev] [lld] Current ways to position memory sections (e.g. .text, .data, .bss) with lld?

[Rafael Auler]

Hi Ed,

I wrote http://reviews.llvm.org/D10952 to address your last problem. There
is also the related http://reviews.llvm.org/D10918 by Denis to address how
you can directly assign sections to segments in the script. Both are in
code review.

Rafael auelr

On Fri, Jul 3, 2015 at 12:29 AM, Rafael Auler <rafaelauler at gmail.com> wrote:

> Hi Ed,
>
> It looks like lld is failing at mapping two sections far apart from each
> other into two different segments. Since it puts these two sections (.text
> and .data) in the same ELF segment, the segment is forced to be huge
> because the start addresses of these sections are far apart from each
> other. I would begin by investigating how
> TargetLayout<ELFT>::assignSectionsToSegments() works and go from there.
> This function lives at lld/lib/ReaderWriter/ELF/TargetLayout.cpp. I don't
> believe you can try any other flags to try to get this done without fixing
> this logic.
>
> Rafael Auler
>
> On Wed, Jul 1, 2015 at 12:00 PM, ed at modk.it <ed at modk.it> wrote:
>
>> Hi All,
>>
>> Congratulations on the major progress on the llvm linker lld over the
>> past year including the new linker script support.  This really makes it
>> possible to ditch binutils altogether.  It looks like lld's MEMORY sections
>> are currently parsed but not evaluated, but so far that hasn't been a
>> problem.
>>
>> The only snag is I can't figure out how to define the start of the .data
>> section in a sane way.  Let's say we want our flash (.text) section to
>> start at address 0x20000 with a max size of 0x8000 bytes and a data section
>> start at 0x20005000 with a max length of 0x3000 bytes.  We'd usually
>> accomplish this with a combination of MEMORY and SECTION entries in the
>> linker script tied together by region aliases, the "AT" directive and the
>> ">" operator:
>>
>> MEMORY
>>
>> {
>>
>>     flash (rx) : ORIGIN = 0x20000, LENGTH = 0x8000
>>
>>     ram (rwx) : ORIGIN = 0x20005000, LENGTH = 0x00003000
>>
>> }
>>
>>
>>  REGION_ALIAS("REGION_TEXT", flash);
>>
>> REGION_ALIAS("REGION_RAM", ram);
>>
>>
>>  SECTIONS
>>
>> {
>>
>>     .text :
>>
>>     {
>>
>>         ...
>>
>>     } > REGION_TEXT
>>
>>
>>
>>     _etext = .;
>>
>>     .data :
>>
>>     {
>>
>>        ...
>>
>>     } > REGION_RAM AT > REGION_TEXT
>>
>>
>> }
>>
>>
>> But the MEMORY entries don't seem to be evaluated and ">", "AT", and
>> "REGION_ALIAS" don't seem to be hooked up either.  Command line options
>> like "-Tdata=org=0x20005000" or "--section-start=.data= 0x20005000" are
>> also not working.
>>
>>
>> However, the following linker script gets us close:
>>
>>
>> SECTIONS
>>
>>     {
>>
>>         . = 0x20000;
>>
>>         .text :
>>
>>         {
>>
>>            ...
>>
>>         }
>>
>>
>>
>>         _etext = .;
>>
>>         . = 0x20005000;
>>
>>         _data = .;
>>
>>         .data :
>>
>>         {
>>
>>            ...
>>
>>         }
>>
>> }
>>
>>
>> The only problem is the resulting elf and binary files are HUGE (e.g. elf
>> is 500mb vs 50k) as the linker seems to be filling the space between the
>> end of text and the beginning of data.  A "llvm-readobj -s" on the
>> resulting elf is nearly identical to one created with binutils except
>> binults-ld puts .data at Address: 0x20005000 Offset: 0xD000 and llvm-lld
>> has data at Address: 0x20005000 Offset: 0x1FFED000 (based on start address
>> of 0x18000.)
>>
>> Any thoughts on a supported linker flag or linker script option that can
>> help here?  Or a source file to dive into to get something working?  I'd be
>> willing to take a pass at completing the MEMORY section implementation if
>> that's the most sane way to move forward but would love a pointer in the
>> right direction.
>>
>>
>> Thanks,
>>
>> Ed
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150706/d7dc0539/attachment.html>