search for: filenode

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

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

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

...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 InputGraph directly. > Yes,...

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 FileNode process() would...

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

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 InputElement if its a FileNode &g...

The --as-needed attribute is preserved and is contained within the ELF FileNode. By lld::files, I am referring to lld::File. Thanks Shankar Easwaran On 9/4/2013 4:10 PM, Rui Ueyama wrote: > On Wed, Sep 4, 2013 at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > >> Yes, the Group is to represent --start-group,--end-group. >> >> So...

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

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

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

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

On 9/5/2013 1:40 PM, Nick Kledzik wrote: > The way darwin works with the current scheme is that the files are added to InputFiles in command line order, then forEachInitialAtom() walks the whole list but only operates on the non-library (i.e. object files) and searchLibraries() only operates on library files. > > If we have the Resolver walk the graph, then either: > 1) We need some

...ity would naturally fall into the InputGraph, in analogy with Groups and Archives. Unfortunately, it's rather more dynamic than the existing cases: we don't know the needed files before parsing the top-level one, and need to open multiple files. Essentially, we'd need to create new MachOFileNodes based on the contents of the parent. It seems there are two obvious ways to do this: 1. Create them while we still have the MachONormalizedFile around; I think this would mean extending the InputGraph::parse interface to allow new InputNodes to be passed back. 2. Add an atom type to represent th...