search for: foreachinitialatom

...Element->processAtom(*this) on > This would essentiall call resolver.processGroup(std::vector<Files>), the vector of files is what makes it in the current group > > 4) InputFiles would be removed > 5) LinkerInput would be removed > 6) Functions that are unused forEachInitialAtom etc > > Issues > > This will essentially break the Darwin model thats in lld, as the current functionalities processes all the object files and only then processes > archive files. > > Can we control by using a resolution policy ? which is a set of boolean flags to control...

...e, the resolver will call inputElement->processAtom(*this) on *This* *would essentiall call resolver.processGroup(std::vector<Files>), the vector of files is what makes it in the current group* 4) InputFiles would be removed 5) LinkerInput would be removed 6) Functions that are unused forEachInitialAtom etc _*Issues*_* *This will essentially break the Darwin model thats in lld, as the current functionalities processes all the object files and only then processes archive files. Can we control by using a resolution policy ? which is a set of boolean flags to control the resolution behavior ? D...

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

...54. 0 0x10fa41098 __assert_rtn + 144 1 0x10fa678af archive::File<x86_64>::makeObjectFileForMember(archive::File<x86_64>::Entry const*) const + 1149 2 0x10fa670fd archive::File<x86_64>::forEachAtom(ld::File::AtomHandler&) const + 645 3 0x10fa7776c ld::tool::InputFiles::forEachInitialAtom(ld::File::AtomHandler&) + 420 4 0x10fa80884 ld::tool::Resolver::resolve() + 44 5 0x10fa41380 main + 370 6 0x10fa32cd4 start + 52 A linker snapshot was created at: /tmp/<Name Removed>-2013-09-22-135411.ld-snapshot ld: Assertion failed: (memberIndex != 0), function makeObjectFileForM...

...1098 __assert_rtn + 144 > 1 0x10fa678af archive::File<x86_64>::makeObjectFileForMember(archive::File<x86_64>::Entry const*) const + 1149 > 2 0x10fa670fd archive::File<x86_64>::forEachAtom(ld::File::AtomHandler&) const + 645 > 3 0x10fa7776c ld::tool::InputFiles::forEachInitialAtom(ld::File::AtomHandler&) + 420 > 4 0x10fa80884 ld::tool::Resolver::resolve() + 44 > 5 0x10fa41380 main + 370 > 6 0x10fa32cd4 start + 52 > A linker snapshot was created at: > /tmp/<Name Removed>-2013-09-22-135411.ld-snapshot > ld: Assertion failed: (memberIndex != 0...

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