[PATCH] [lld] add InputGraph to process Command line arguments

[Shankar Easwaran]

Hi Rafael,

The current implementation / design handles like how you mentioned but 
Inputs need to know to what group do they belong for how to process 
them. The InputElement as part of each control node, has a parent 
associated with it.

In the below example :-

lld main.o --start-group libc.a libma --as-needed libpthread.so 
--no-as-needed --end-group -o a.out

libc.a libm.a are part of a group and that information would be needed 
when you process the group.

May be the name needs to be changed ... I am open for suggestions.

Thanks

Shankar Easwaran

On 7/25/2013 11:19 AM, Rafael Espíndola wrote:
> This looks like an overkill. Cant we go directly form argv to a list
> of Inputs? An input in this context is one of
>
> * A plain object file
> * An archive, with some simple boolean options (load all elements)
> * A group (which is a list of other inputs)
> * A begin-lib/end-lib "area".
>
> I don't see where we need a general graph structure.
>
>
> On 25 July 2013 12:06, Shankar Kalpathi Easwaran <shankarke at gmail.com> wrote:
>> Hi Bigcheese, kledzik, ruiu,
>>
>> Before it gets too far, I thought let me get the initial work reviewed to process command line arguments into a Graph form.
>>
>> The functionality addresses Command line arguments by creating a Graph which contains InputElements. The InputElements are nodes that contain InputFile information or Control Information.
>>
>> The InputFile information in addition to containing a file, contains positional options that deal with this InputFile.
>> For example --force-load libc.a --no-force-load (We only want to force load libc.a and no other libraries).
>>
>> The Control information is another kind of InputElement which  contains information on how the resolver would need to deal with (For example : --start-group, --end-group).
>>
>> The InputElements that are part of the InputGraph also has two additional fields
>>
>> a) Ordinal (The ordinal value sets the order of the InputElement in the graph)
>> b) Weight (Associates a weight to the InputElement). Could be used to get statistics.
>>
>> The global options are still dealt with by placing them in TargetInfo as earlier. If we want to change this, I will accomodate to any changes in design.
>>
>> Still todo functionalities :-
>>
>> a) Address review comments
>> b) Add tests
>> b) Add functionality to dump the InputGraph to Text/YAML.
>> c) Add functionality to validate
>> d) Expand an input element
>>
>> More importantly the FileNode needs to be attached to lld Core functionality so that lld can query for flavor specific options when it deals with individual files.
>>
>> What I have done till now is
>>
>> Changed the ELF flavor to create InputGraph nodes and populate options and convert all the regular options that deal with.
>>
>> http://llvm-reviews.chandlerc.com/D1217
>>
>> Files:
>>    include/lld/Driver/ELFInputGraph.h
>>    include/lld/Driver/InputGraph.h
>>    lib/Driver/CMakeLists.txt
>>    lib/Driver/ELFInputGraph.cpp
>>    lib/Driver/GnuLdDriver.cpp
>>    lib/Driver/InputGraph.cpp
>>    lib/Driver/LDOptions.td
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>


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