[PATCH] D19976: [ELF] - Prototype of possible linkerscript redesign.

[George Rimar via llvm-commits]

grimar added a comment.

In http://reviews.llvm.org/D19976#423173, @ruiu wrote:

> Before going into details, can I ask you if you think this is going to be able to support all the linker script features? Is there any concerns/limitations on it?


I think this approach should be pretty efficient.
I reviewed again freebsd script and I think all commands it uses can be implemented with this approach without
hacks or anything alike. I can not imagine a real limitations. The way it works seems very natural to me,
because of 2 main steps that are separated and do not cross at all.

1. Creating sections and processing all commands inside declaration to finally get

a output section as a black box for future use. This allows to make any internal layout and 
support every internal command (it seems). The fact that location counter
meaning inside declaration differs from meaning outside very helpfull here and strengthens my faith.
For example PROVIDE inside declarations is easy to support because we know (.) value that is offset here,
we can move it, align or whatever we want, we can place sections in the order we want, sort them, keep or discard,
that all is also easy because on each step we have direct access to linkerscipt commands and have no any other
task except "create output section".

2. Assign addresses and processing external to sections declarations commands is very comfortable to do now.

For example PROVIDE on that step requires global (.) value and that is what easily we can give it.
We do not need to bother here with internals of sections, because external commands can not affect them and
we already have sections created at step 1, so we skip all that stuff during processing.
We don't need to sort them here, as it is assumed they are already sorted after step 1.
And again we have direct access to linkerscript sections commands on this step as well
(actually current code gives ability to read/interpret them at any point of program), so we definetely should
be able to implement everything we might want, since there is no any information lost.

Now about my conserns.
The only I have is about processing predefined sections. 
Now in this patch they are not processed, so they are just added to the end of outputsections list
in addPredefinedSections(). I think since script is responsible for full layout now, them should be processed
on its side either. So I mean if we see (for example):

  .got            : { *(.got) }
  .got.plt        : { *(.got.plt) }

Then we want to place Out<ELFT>::Got and Out<ELFT>::GotPlt in that order in some generalized way.
We can probably just add all predefined sections to the end 
and then sort the list at the end of step 1, since we know their names and we have matching pattern.
Or we can assume that ".got" is always Out<ELFT>::Got and so on, or process them in some nicer way. 
So that is definetely possible, just requires some attention for clean implementation.
I would leave that for futher patches.


http://reviews.llvm.org/D19976