search for: dies

> In beginModule, we construct the CUs, but not all the DIEs that belong to >>> the CU. >>> In endFunction, we started to construct the scope DIEs. So in some >>> sense, we are adding things to prior CUs. >>> >>> Looking at void CompileUnit::addDIEEntry(DIE *Die, uint16_t Attribute, >>> DIE *Entry), we ca...

On Wed, Oct 16, 2013 at 10:54 AM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> In beginModule, we construct the CUs, but not all the DIEs that belong >>>>> to the CU. >>>>> In endFunction, we started to construct the scope DIEs. So in some >>>>> sense, we are adding things to prior CUs. >>>>> >>>>> Looking at void CompileUnit::addDIEEntry(DIE *Die, uint16_t At...

...On Wed, Oct 16, 2013 at 10:54 AM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com>wrote: >> >>> >>> In beginModule, we construct the CUs, but not all the DIEs that >>>>>> belong to the CU. >>>>>> In endFunction, we started to construct the scope DIEs. So in some >>>>>> sense, we are adding things to prior CUs. >>>>>> >>>>>> Looking at void CompileUnit::addDIEEntry(D...

On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com> wrote: > > In beginModule, we construct the CUs, but not all the DIEs that belong >>>> to the CU. >>>> In endFunction, we started to construct the scope DIEs. So in some >>>> sense, we are adding things to prior CUs. >>>> >>>> Looking at void CompileUnit::addDIEEntry(DIE *Die, uint16_t Attribute, >>&gt...

...fail? Can you describe a specific sequence where the worklist is >>>>>>>>>>>>> necessary? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If we are sure that DIEs are always added to an owner before >>>>>>>>>>>> calling addDIEEntry, we don't need the worklist. >>>>>>>>>>>> But I saw cases where that was not true, I will get a reduced >>>>>>>>>>>> t...

...;>> tests fail? Can you describe a specific sequence where the worklist is >>>>>>>>>>>> necessary? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If we are sure that DIEs are always added to an owner before >>>>>>>>>>> calling addDIEEntry, we don't need the worklist. >>>>>>>>>>> But I saw cases where that was not true, I will get a reduced >>>>>>>>>>> testing case....

...AM, Manman Ren <manman.ren at gmail.com>wrote: >> >>> >>> >>> >>> On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com>wrote: >>> >>>> >>>> In beginModule, we construct the CUs, but not all the DIEs that >>>>>>> belong to the CU. >>>>>>> In endFunction, we started to construct the scope DIEs. So in some >>>>>>> sense, we are adding things to prior CUs. >>>>>>> >>>>>>> Looking at void Compil...

...E(llvm::LexicalScope*) 8.19 MB 0.8% 33547 llvm::DwarfCompileUnit::constructImportedEntityDIE(llvm::DIImportedEntity const*) A lot of this is the pair of `SmallVector<, 12>` it has for its values (look into `DIEAbbrev` for the second one). Here's a histogram of how many DIEs have each value count: # of Values DIEs with # with # or fewer 0 3128 3128 1 109522 112650 2 180382 293032 3 90836 383868 4 115552 499420...

...t;> >>>> When building xalan with "lto -g", I saw 3158 violations of the >>>> assumption. Should we try to fix all these violations to make the >>>> assumption true? >>>> >>> >>> As you've said, this assumption (that DIEs are always constructed by the >>> CU that will own them) isn't necessary for this patch - it will be >>> necessary for cu-at-a-time emission. Perhaps we should discuss it in a >>> separate thread rather than trying to make a stronger assumption than is >>> ne...

...;>>>>>> tests fail? Can you describe a specific sequence where the worklist is >>>>>>>>>>> necessary? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If we are sure that DIEs are always added to an owner before >>>>>>>>>> calling addDIEEntry, we don't need the worklist. >>>>>>>>>> But I saw cases where that was not true, I will get a reduced >>>>>>>>>> testing case. >>&gt...

...>>>>>>>>>> tests fail? Can you describe a specific sequence where the worklist is >>>>>>>>>> necessary? >>>>>>>>>> >>>>>>>>> >>>>>>>>> If we are sure that DIEs are always added to an owner before >>>>>>>>> calling addDIEEntry, we don't need the worklist. >>>>>>>>> But I saw cases where that was not true, I will get a reduced >>>>>>>>> testing case. >>>>>&gt...

...AM, Manman Ren <manman.ren at gmail.com>wrote: >> >>> >>> >>> >>> On Tue, Oct 15, 2013 at 5:59 PM, David Blaikie <dblaikie at gmail.com>wrote: >>> >>>> >>>> In beginModule, we construct the CUs, but not all the DIEs that >>>>>>> belong to the CU. >>>>>>> In endFunction, we started to construct the scope DIEs. So in some >>>>>>> sense, we are adding things to prior CUs. >>>>>>> >>>>>>> Looking at void Compil...

Hi, I could install Orcs Must Die, but when I try to run it, I get the following errors: Code: err:module:import_dll Library fmod_event.dll (which is needed by L"C:\\Programme (x86)\\Robot Entertainment\\Orcs Must Die!\\Build\\release\\OrcsMustDie.exe") not found err:module:import_dll Library lua90.dll (which is needed by L"C:\\Programme (x86)\\Robot Entertainment\\Orcs Must

...p;& "Unable to find subprogram DIE!"); DISubprogram SP(SPNode); // If we're updating an abstract DIE, then we will be adding the children and // object pointer later on. But what we don't want to do is process the // concrete DIE twice. if (DIE *AbsSPDIE = AbstractSPDies.lookup(SPNode)) { // Pick up abstract subprogram DIE. SPDie = new DIE(dwarf::DW_TAG_subprogram); SPCU->addDIEEntry(SPDie, dwarf::DW_AT_abstract_origin, dwarf::DW_FORM_ref4, AbsSPDIE); SPCU->addDie(SPDie); } … } The compile unit DIE where AbsSPDIE belon...

...0x00000ee3: DIE attribute 0x00000ee4: AT_type/FORM_ref4 has a value 0x00001285 that is not in the current compile unit in the .debug_info section. > On Linux - well the problem here is that even when my DWARF info was working, dwarfdump would spit out a ton of error messages about bad file DIEs and other spam - in other words, I've never been able to use LLVM to produce a binary on Linux that was dwarfdump-error free. So any "new" errors are mixed in with all of the "old" errors I was seeing before. > 3) Use llbrowse to manually inspect the DIEs and see if they...

I recently started getting this error when I try to debug my LLVM-compiled program in GDB: Dwarf Error: Cannot find DIE at 0x16769 referenced from DIE at 0x1713c [in module /home/talin/Projects/tart/build-eclipse/test/stdlib/ReflectionTest] I'm not sure if it's something I did or not. Is there any way to track down the cause of this error? The hex addresses in the error message are

...ed that logic, would >>>>>>>>> tests fail? Can you describe a specific sequence where the worklist is >>>>>>>>> necessary? >>>>>>>>> >>>>>>>> >>>>>>>> If we are sure that DIEs are always added to an owner before >>>>>>>> calling addDIEEntry, we don't need the worklist. >>>>>>>> But I saw cases where that was not true, I will get a reduced >>>>>>>> testing case. >>>>>>>> &g...

...> cover the need for the worklist? ie: if we removed that logic, would tests >>>>>>>> fail? Can you describe a specific sequence where the worklist is necessary? >>>>>>>> >>>>>>> >>>>>>> If we are sure that DIEs are always added to an owner before calling >>>>>>> addDIEEntry, we don't need the worklist. >>>>>>> But I saw cases where that was not true, I will get a reduced >>>>>>> testing case. >>>>>>> >>>>&g...

...0000ee3: DIE attribute 0x00000ee4: AT_type/FORM_ref4 has a value 0x00001285 that is not in the current compile unit in the .debug_info section. - On Linux - well the problem here is that even when my DWARF info was working, dwarfdump would spit out a ton of error messages about bad file DIEs and other spam - in other words, I've never been able to use LLVM to produce a binary on Linux that was dwarfdump-error free. So any "new" errors are mixed in with all of the "old" errors I was seeing before. 3) Use llbrowse to manually inspect the DIEs and see if the...

...is missing > from the output. There are other uses of DW_FORM_ref4 also. So check in our > dwarfdump output what is 0x00000883 and set appropriate breakpoint in > debugger and see why it is not reaching to DwarfDebug::emitDIE(). > OK I've been checking this out some more, and the DIEs don't look valid to me. Take a look at this output from dwarfdump -v: 0x000000c7: TAG_subprogram [3] 0x000000c8: AT_name( .debug_str[0x000001bd] = "construct" ) 0x000000cc: AT_MIPS_linkage_name( .debug_str[0x000001c7] = "tart.reflect.Parameter.construct(tart.core.S...