search for: inputgraph

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

...hanks Shankar Easwaran On 9/4/2013 5:50 PM, Nick Kledzik wrote: > 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 was the abstract interface that he Resolver used to see all the inputs. If InputGraph supported the methods forEac...

...> On 9/4/2013 5:50 PM, Nick Kledzik wrote: >> 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 was the abstract interface that he Resolver used to see all the inputs. If InputGraph supported the...

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 was the abstract interface that he Resolver used to see all the inputs. If InputGraph supported the methods forEachInital...

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

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

...pler and also captures the darwin difference that all libraries are always repeatedly searched. > > -Nick One way, I can think of this being done is to get all the libraries that are specified in the command line and create a group node, and add it after the command line is processed to the inputGraph. PS : Does Darwin have a command line option to handle files in the order specified in the command line for libraries ? If so, then the above would break I am planning to support other operations too like inputElement->setPosition(InputGraph::Top) inputElement->setPosition(InputGraph::La...

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

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 really means the last f...

...ent notification. > > How does the Resolver detect an infinite loop? As in the example below, it is supposed to keep getting a,b,c,a,b,c… At some point, no more undefines are being fulfilled by a,b,c,a,b,c…, but how does the resolver know that the files are repeating, to know to tell the InputGraph to move on? > > nextFile() should returns the same file objects for the same file, so Resolver can notice if it haven't resolved any symbol since last time it saw the same file. That is not how groups work. The resolver has to keep checking each file in the group, in order, until ther...

Hey there, lld fails to build on Visual Studio 2013 because of ErrorOr<void>. For example, ErrorOr<void> is used in InputGraph.h as the return type of InputGraph::reset. Inside of ErrorOr, there is: typedef typename remove_reference<T>::type &reference As T is void, and remove_reference <T>::type results in void, the typedef expands to: typedef void & reference, which looks rather invalid. So the punch...

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

...k I removed all uses of ErrorOr<void>. Can you try updating? On 15 November 2013 12:09, Daniel Albuschat <d.albuschat at gmail.com> wrote: > Hey there, > > lld fails to build on Visual Studio 2013 because of ErrorOr<void>. > For example, ErrorOr<void> is used in InputGraph.h as the return type > of InputGraph::reset. > Inside of ErrorOr, there is: > typedef typename remove_reference<T>::type &reference > As T is void, and remove_reference <T>::type results in void, the > typedef expands to: > typedef void & reference, which looks...

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

...am trying to consider for the linker internal atoms to appear in the output YAML file are :- a) Replace Writer::addFiles to Reader::addFiles This would achieve any file to be added to the list of input files that is processed. (or) b) Create a seperate API in the inputGraph for the driver to add lld::Files, that are consumed by the Universal driver and that gets added to the list of File objects that is being considered (or) c) Handle all the command line switches of -u or any atoms that we want to see them appear in the YAML file as...

...; How does the Resolver detect an infinite loop? As in the example below, >> it is supposed to keep getting a,b,c,a,b,c… At some point, no more >> undefines are being fulfilled by a,b,c,a,b,c…, but how does the resolver >> know that the files are repeating, to know to tell the InputGraph to move >> on? >> > > nextFile() should returns the same file objects for the same file, so > Resolver can notice if it haven't resolved any symbol since last time it > saw the same file. > > That is not how groups work. The resolver has to keep checking each file...

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

...ple, 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 p...

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 top-level one, and need to open multiple files. Essentially, we'd need to create new MachOFileNodes based on the contents of the paren...

...t 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 <shankare at codeaurora.org> wrote: > 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...