llvm dev - Jan 2013 - [LLVMdev] [lld] Linker script findings.

On Wed, Jan 2, 2013 at 12:04 PM, Shankar Easwaran
<shankare at codeaurora.org> wrote:
> You might want to look at the ELFLayout changes to see what functionality
is
> missing from that.
>
> The ELFLayoutOptions has a hook into reading the Linker script which needs
> to be implemented.
So, looking into it a bit, I think that ELFLayoutOptions is not the
right place to parse the linker script. From what I can tell, it has
to be parsed during argument processing. As Nick pointed out, most of
the linker script stuff can be handled during the final writing stage,
but since the script can define symbols, it has to be parsed earlier.
Also, Nick's perspective was that "the linker scripts and the command
line arguments should all be parsed into one set of "options" to the
ELF Writer".

-- Sean Silva

On Jan 6, 2013, at 2:05 PM, Sean Silva wrote:
> but since the script can define symbols, it has to be parsed earlier.
It is more than just defining symbols.  There are many other directives that
have command line option equivalents that are used to setup linking.  You can
pull symbols
with EXTERN, add other files to link with INPUT, add groups of archives to be
searched
with GROUP, name the output file with OUTPUT, add new library path directories
with SEARCH_DIR, etc…

Also keep in mind that that linker scripts are usually "inlined" with
other command line
options.  For example:

   ld foo.o --defsym=x=12 -Lbar -T beagle-ram.ld -lbaz bar.o

As you said, it makes sense to parse it during command line argument parsing.

--
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software

Hi Sean,

The hook to add symbols into the Reader is through Writer->addFiles 
function. I think still the linker script should be parsed by Writer.

Also the linker script functionality is only needed by ELF and not 
anything else. It should be contained only within ELF.

Thanks

Shankar Easwaran

On 1/6/2013 2:05 PM, Sean Silva wrote:
> On Wed, Jan 2, 2013 at 12:04 PM, Shankar Easwaran
> <shankare at codeaurora.org> wrote:
>> You might want to look at the ELFLayout changes to see what
functionality is
>> missing from that.
>>
>> The ELFLayoutOptions has a hook into reading the Linker script which
needs
>> to be implemented.
> So, looking into it a bit, I think that ELFLayoutOptions is not the
> right place to parse the linker script. From what I can tell, it has
> to be parsed during argument processing. As Nick pointed out, most of
> the linker script stuff can be handled during the final writing stage,
> but since the script can define symbols, it has to be parsed earlier.
> Also, Nick's perspective was that "the linker scripts and the
command
> line arguments should all be parsed into one set of "options" to
the
> ELF Writer".
>
> -- Sean Silva
>
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

On 1/6/2013 6:30 PM, Meador Inge wrote:
> On Jan 6, 2013, at 2:05 PM, Sean Silva wrote:
>
>> but since the script can define symbols, it has to be parsed earlier.
> It is more than just defining symbols.  There are many other directives
that
> have command line option equivalents that are used to setup linking.  You
can pull symbols
> with EXTERN, add other files to link with INPUT, add groups of archives to
be searched
> with GROUP, name the output file with OUTPUT, add new library path
directories
> with SEARCH_DIR, etc…
>
> Also keep in mind that that linker scripts are usually "inlined"
with other command line
> options.  For example:
>
>     ld foo.o --defsym=x=12 -Lbar -T beagle-ram.ld -lbaz bar.o
This is different. There are things in the command line which would

a) add symbols into the output
     This is generic functionality which is needed by all the platforms. 
The symbols could be parsed and handed over to ELF Writer to add 
symbols, because types of symbols on what to add should be owned by the 
target specific format.

b) specify segment address by using (-Ttext=<n>)
     This functionality is only needed by ELF and should be contained in 
WriterELF.

Overall, I think that the functionality should be accessed only by 
WriterELF and contained within.

Nick, Michael : What do you think ?

Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

On Mon, Jan 7, 2013 at 9:44 AM, Shankar Easwaran
<shankare at codeaurora.org> wrote:
> Also the linker script functionality is only needed by ELF and not anything
> else. It should be contained only within ELF.
I agree with your point about encapsulation and separation of
concerns. However, I believe that GNU ld will accept and use linker
scripts even for the non-ELF formats it supports (not that we intend
to emulate that behavior necessarily), so they aren't ELF-specific per
se. Thus I feel that the right categorization might be "GNU ld"-only,
and hence it would naturally be just a component of the GNU ld
frontend, where it would be isolated from the rest of LLD.

-- Sean Silva

On Jan 7, 2013, at 9:44 AM, Shankar Easwaran <shankare at codeaurora.org>
wrote:
> Also the linker script functionality is only needed by ELF and not anything
else. It should be contained only within ELF.
I don't have an opinion on where it is needed, but I've found linker
scripts to be useful in other contexts. Here's a simple one I wrote that has
no relation to ELF:

OUTPUT_FORMAT(binary)
OUTPUT(flash.bin)
SECTIONS
{
        .text :
        {
                . = 0x2000;
                LONG(0xAABBCCDD);
                LONG(Init);
                LONG(Store);
                LONG(Erase);
                LONG(Write);
                *(.text)
                *(.rodata)
        }
}

(The documentation seemed to imply that I could write .text 0x2000 : AT(0), but
that never worked for me, so I just stripped off 0x2000 bytes of 0 at the
beginning.)

Maybe there's a way to do that without linker scripts, but this was very
easy.

All of this is to say if it's not a lot of extra work, linker scripts should
be supported outside of ELF.

-- 
Stephen Checkoway