search for: foreachinitialatom

Displaying 7 results from an estimated 7 matches for "foreachinitialatom".

Did you mean: foreachinitalatom
2013 Sep 05
0
[LLVMdev] [lld] Modeling ELF FileNodes/ControlNodes (Group's) in lld
...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...
2013 Sep 05
2
[LLVMdev] [lld] Modeling ELF FileNodes/ControlNodes (Group's) in lld
...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...
2013 Sep 05
1
[LLVMdev] [lld] Modeling ELF FileNodes/ControlNodes (Group's) in lld
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...
2013 Oct 22
4
[LLVMdev] ld: Assertion failed: (memberIndex != 0), function makeObjectFileForMember
...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...
2013 Oct 23
0
[LLVMdev] ld: Assertion failed: (memberIndex != 0), function makeObjectFileForMember
...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...
2013 Sep 04
0
[LLVMdev] [lld] Modeling ELF FileNodes/ControlNodes (Group's) in lld
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
2013 Sep 04
3
[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