llvm dev - Sep 2013 - [LLVMdev] [lld] Modeling ELF FileNodes/ControlNodes (Group's) in lld

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

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>

Yes, the Group is to represent --start-group,--end-group.

So the group here will be contained in the linker Input as a vector of 
lld::files (foo.a, bar.a).

thanks

Shankar Easwaran

On 9/4/2013 3:59 PM, Rui Ueyama wrote:
> 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
>>
>>

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

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.

Originally InputFiles was the abstract interface that he Resolver used to see
all the inputs.  If InputGraph supported the methods  forEachInitalAtom() and
searchLibraries() then we could get rid of InputFiles and have the Resolver uses
InputGraph directly.

What should the interface be that the Resolver uses for handling groups?  

-Nick

On 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

Hi Nick,

On 9/4/2013 4:04 PM, Nick Kledzik wrote:
> I do think we have too many classes.
Agree.
>   I thought InputGraph was going to replace InputFiles.
Interesting idea.
>   It seems link LinkerInput could be merged into FileNode.
Agree.
>
> Originally InputFiles was the abstract interface that he Resolver used to
see all the inputs.  If InputGraph supported the methods  forEachInitalAtom()
and searchLibraries() then we could get rid of InputFiles and have the Resolver
uses InputGraph directly.
Yes, this would be nice. I will try to write a proposal in the next few 
days.
> What should the interface be that the Resolver uses for handling groups?
bool resolveUndefines(std::vector<File> &files) ?

This has to iterate over the files until it reaches a stable point (that 
no more resolution is possible).

Thanks

Shankar Easwaran
>
> -Nick
>
> On 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
>
>

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

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

On Wed, Sep 4, 2013 at 2:04 PM, Nick Kledzik <kledzik at apple.com> 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.
>
> Originally InputFiles was the abstract interface that he Resolver used to
> see all the inputs.  If InputGraph supported the methods
>  forEachInitalAtom() and searchLibraries() then we could get rid of
> InputFiles and have the Resolver uses InputGraph directly.
>
This is how I imaginged it would work.

- Michael Spencer

>
> What should the interface be that the Resolver uses for handling groups?
>
> -Nick
>
> On 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/6ccd9e27/attachment.html>