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

Rui Ueyama ruiu at google.com
Wed Sep 4 13:59:48 PDT 2013


The first question is that Group is to represent --start-group/--end-group?

If I understand your proposal correctly, here's the thing: if file is not
in group, each individual file is wrapped with LinkerInput, but if it's in
a group, it's not -- instead the entire group is wrapped with a
LinkerInput. This asymmetry is a bit concerning. If we don't need a
LinkerInput for each individual input file, we could get rid of it from the
former case. Otherwise, I'd think we need LinkerInput in the latter case.

For example, if the following command line options are given, how it's
represented with LinkerInput, Group and File?

 --start-group foo.a --as-needed bar.a --no-as-needed --end-group

On Wed, Sep 4, 2013 at 1:42 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:

> Hi,
>
> With the inputGraph now, lld models command line options, input files as
> nodes in the InputGraph called InputElements.
>
> In the current approach, each InputElement is converted to a LinkerInput,
> which works if all lld deals with individual files.
>
> Dealing with ControlNodes (Groups), have a problem with it, on how to
> model that as a LinkerInput.
>
> Joerg/Me were chatting on the IRC about this and we came up with the
> following approach.
>
> - LinkerInput will contain a single file(lld::File), if the node that its
> pointing to appears to be a FileNode
> - LinkerInput will contain a vector(lld::Group) of files(lld::Files) , if
> the node that its pointing appears to be a Group
>
> The resolver would need to be modified to consider lld::Groups in addition
> to lld::File.
>
> Does this sound like the approach we want to take ?
>
> Thanks
>
> Shankar Easwaran
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by the Linux Foundation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130904/2a53791b/attachment.html>


More information about the llvm-dev mailing list