search for: filenodes

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

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 >

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

On 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

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

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

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

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 the group here will

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

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 the group here will be contained in the linker Input as a vector of > lld::files (foo.a, bar.a). It seems you dropped --as-needed attribute... ? By lld::files, what class are you pointing to, lld::File or lld::InputFiles?

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

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

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