[LLVMdev] [lld] Modeling ELF FileNodes/ControlNodes (Group's) in lld

[Shankar Easwaran]

Hi Joerg,

I  like the approach that Nick mentioned, that, if there is a way to 
structure the resolver around InputGraph, it makes things much easier.

You can have different flavors of linking so easily(because that is 
where we finally want, with lld supporting multiple flavors of linking).

We could have a ResolverPolicy which the InputGraph could take in and 
resolve files in any style.

Thanks

Shankar Easwaran


On 9/4/2013 4:39 PM, Joerg Sonnenberger wrote:
> On Wed, Sep 04, 2013 at 02:04:14PM -0700, Nick Kledzik wrote:
>> I do think we have too many classes.  I thought InputGraph was going
>> to replace InputFiles.  It seems link LinkerInput could be merged into
>> FileNode.
> I both agree and disagree. Logically we have two different views, the
> command line and the resulting input tree on the side and the groups of
> object files as seen by the resolver on the other side. The goal of
> parseFile is ultimately to transform the first into the second. Agreed
> so far?
>
> Want I want to do is encapsulate the "command line" side in LinkerInput,
> that means the "logical" path used for error reporting and the buffers
> associated with the input. The resolver side should not be involved with
> either. I see D1598 (changing parseFile to take LinkerInput) as
> necessary step toward D1587 and related changes, i.e. the ability to
> properly represent positional flags and hand that information down.
>
> This now leaves out the question whether the command line view and the
> resolver view should have the same classes or not. I am not at the point
> yet where I can tell what the best behavior is. I can see good reasons
> for a strict separation in the class tree, but it may also be more
> artifical as separation than necessary.
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


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