search for: searchlibrari

...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. I will try to write a proposal in the next few days. >> What should the interface be that the Resolver uses for handling groups? > bool resolveUndefines(std::vector<File...

...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. I will try to write a proposal in the next few days. > What should the interface be that the Resolver uses for handling groups? bool resolveUndefines(std::vector<File> &fil...

...ace 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. I will try to write a proposal in the next few days. >>> What should the interface be that the Resolver uses for handling groups? >> bool resolveUndefines(std::ve...

...lean flags to control the resolution behavior ? Do you have any other approach ? 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 option for darwin and gnu to work differently, or 2) Have the darwin driver construct the graph with all libraries in one group at the end. As long as that is straight forward to do, it see...

...nk 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 Resolver uses for handling groups? -Nick On Sep 4, 2013, at 1:42 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi, > > With the inputGraph...

...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 how I imaginged it would work. - Michael Spencer > > What should the interface be that the Resolver uses for handling groups? > > -Nick > > On Sep 4, 2013, at 1:42 PM, Sha...

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 option for darwin and gnu to work differently, or > 2) Have the darwin driver construct the graph with all libraries in one group at the end. As long as that is straight forwa...

...= Comment at: lib/Core/Resolver.cpp:214 @@ +213,3 @@ + // for COFF "weak external" symbol. + const UndefinedAtom *fallbackUndefAtom = undefAtom->fallback(); + if (fallbackUndefAtom) { ---------------- You need to re-test: if (!_symbolTable.isDefined(undefName) because searchLibraries() may have already found a definition. http://llvm-reviews.chandlerc.com/D1550 _______________________________________________ llvm-commits mailing list llvm-commits at cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits -------------- next part -------------- An HTML attachm...

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

...> @@ +213,3 @@ > + // for COFF "weak external" symbol. > + const UndefinedAtom *fallbackUndefAtom = undefAtom->fallback(); > + if (fallbackUndefAtom) { > ---------------- > You need to re-test: > if (!_symbolTable.isDefined(undefName) > because searchLibraries() may have already found a definition. > > > http://llvm-reviews.chandlerc.com/D1550 > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > > > >...

...// for COFF "weak external" symbol. >> + const UndefinedAtom *fallbackUndefAtom = undefAtom->fallback(); >> + if (fallbackUndefAtom) { >> ---------------- >> You need to re-test: >> if (!_symbolTable.isDefined(undefName) >> because searchLibraries() may have already found a definition. >> >> >> http://llvm-reviews.chandlerc.com/D1550 >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commit...

...;weak external" symbol. >>> + const UndefinedAtom *fallbackUndefAtom = undefAtom->fallback(); >>> + if (fallbackUndefAtom) { >>> ---------------- >>> You need to re-test: >>> if (!_symbolTable.isDefined(undefName) >>> because searchLibraries() may have already found a definition. >>> >>> >>> http://llvm-reviews.chandlerc.com/D1550 >>> _______________________________________________ >>> llvm-commits mailing list >>> llvm-commits at cs.uiuc.edu >>> http://lists.cs.uiuc.ed...