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

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

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

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

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

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

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

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

Hi all, I've been thinking about how best to represent MachO's LC_REEXPORT_DYLIB (used even by libSystem.dylib to provide its various sub-components[*]). It looks like this functionality 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

Hi, Right now, linker added symbols specified by the -u option do not endup in the output YAML file. This is because the target specific Writers dont get called, which creates the undefined atoms. I am in the process of adding more options and I would like the atoms created internally by the options available in the output YAML file. The options that I am trying to consider for the linker

Hi Nick, The problem is when the -emit-yaml option is used, the writer is set to the YAML writer. The YAML writer doesnot have anything to add here. The problem can be solved by having the YAML writer append a list of undefined atoms specified by the -u option, but the problem I have is each flavor has extra command line options for which it wants to create a DefinedAtom/UndefinedAtom. The

Shankar, The LinkingContext has a addImplictFiles() method that is supposed to call the Writer and give it a chance to add any implicit files. Is the problem that the -u atoms are not attached to that implicit file? Or that the implicit file is not getting added? Or that this got lost in the transition from InputFiles to InputGraph? -Nick On Aug 28, 2013, at 2:44 PM, Shankar Easwaran

Shankar, I think your proposal and mine are pretty much the same. The difference is passing back info to the InputGraph as a parameter in nextFile() vs as a separate method call. My original draft email had a parameter in nextFile(), but it seemed a little confusing because the information was referring to the previous file. That is, if the current resolver state has newDefinedAtoms, that

On Aug 28, 2013, at 3:14 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > The problem is when the -emit-yaml option is used, the writer is set to the YAML writer. Ah! > > The YAML writer does not have anything to add here. > > The problem can be solved by having the YAML writer append a list of undefined atoms specified by the -u option, but

Shankar and I discussed input file handling, and we came up with a design that may greatly simplify the input file handling, while giving more flexibility to developer to support complicated options, such as --{start,end}-group, -z rescan or -z rescan-now. It'd worth pursuing, so here's the idea: 1. We wouldn't probably want to let Resolver to handle the input graph directly, for we

On Sep 20, 2013, at 3:37 PM, Rui Ueyama <ruiu at google.com> wrote: > On Fri, Sep 20, 2013 at 3:29 PM, Nick Kledzik <kledzik at apple.com> wrote: > Rui, > > I like this in general, but have a few questions. > > On Sep 20, 2013, at 2:30 PM, Rui Ueyama <ruiu at google.com> wrote: > >> 2. We would instead add a new method nextFile() to LinkingContext,