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

[George Rimar via llvm-commits]

grimar added a comment.

In http://reviews.llvm.org/D19976#473736, @davide wrote:

> Thanks for taking care of this, George.
>  The first question that comes to my mind is: how is this code going to support expression relative to sections? When we do symbol assignment a symbol may be relative to a section so we need to be able to fetch the section (which was a little bit of a stretch in the current code).


Core idea of the patch turns around LayoutParser class that has run(Callback C) method. It can be used in any place of code,
providing the ability to retrive and proccess linker script section's tag commands that are actual for the place of call.
So speaking about expressions relative to sections: patch has LinkerScript<ELFT>::createSections() method that
main intend is to create all sections and process all commands that are inside output section declararions (including expressions and everything else).
Since location pointer inside output section declaration is relative to section and we have access to all linkerscript commands at that point,
we should be able to process them and perform any layout and expression calculations we want. Just because we have everything for that at this point.

> My second question is:

>  Can you defend the ability of your code being able to implement cleanly more complex constructs? e.g.

> 

>   KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))

>   KEEP (*(SORT(.dtors.*)))

> 


We should be able to do that because will have access to all sections tag commands of script at any point and will be able to process them using custom callback we put to LayoutParser::run(Callback C). We might need to extend enum CommandKind with more types of commands and update the callback(s) properly.
What nice here that linkerscript code will be updated only in part of adding new commands to CommandKind. 
And callback(s) can handle everything else.
Speaking about how clean it can be: everything will depend on callback implementation here. I believe it should be possible to implement nice and clean ones.


http://reviews.llvm.org/D19976