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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150701/40bf8d86/attachment.html>

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/20150703/2a6b6e7d/attachment.html>

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>