search for: linkerinput

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),...

...o.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 ne...

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 th...

...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 >>&gt...

...> > 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. Other...

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 sh...

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 dir...

...Sep 4, 2013, at 2:32 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > 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...

Hi Nick, These are the below modifications needed in lld to start processing groups :- 1) LinkerInput would be moved to FileNode that contains the following functions - getBuffer - takeBuffer - getPath 2) The driver will process the vector of InputElements and call /*process */on each of them. process() would create a lld::File object within the InputElement if its a Fil...

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 I...

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...

On Sep 4, 2013, at 9:28 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > These are the below modifications needed in lld to start processing groups :- > > 1) LinkerInput would be moved to FileNode that contains the following functions > - getBuffer > - takeBuffer > - getPath > > 2) The driver will process the vector of InputElements and call process on each of them. > process() would create a lld::File object within the InputE...