search for: die

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

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

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

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, >>&g...

...>>> >>>>>>>>>>>> computeSizeAndOffset takes an offset that is relative to the >>>>>>>>>>>> start of the CU and returns the offset relative to the CU after laying out >>>>>>>>>>>> the DIE. >>>>>>>>>>>> The initial offset before laying out the CU DIE is the header >>>>>>>>>>>> size, EndOffset will be the offset relative to the CU after laying out the >>>>>>>>>>>> whole CU DIE....

...>>>>>> >>>>>>>>>>> computeSizeAndOffset takes an offset that is relative to the >>>>>>>>>>> start of the CU and returns the offset relative to the CU after laying out >>>>>>>>>>> the DIE. >>>>>>>>>>> The initial offset before laying out the CU DIE is the header >>>>>>>>>>> size, EndOffset will be the offset relative to the CU after laying out the >>>>>>>>>>> whole CU DIE. >>>...

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

...ing things onto BumpPtrAllocators, really leak them with malloc()). (I've collected this data on top of a few not-yet-committed patches to cheapen `MCSymbol` and `EmitLabelDifference()` that chop around 8% of memory off the top, but otherwise these numbers should be reproducible in ToT.) The `DIE` class is huge. Directly, it accounts for about 15% of backend memory: Bytes Used Count Symbol Name 77.87 MB 8.4% 318960 llvm::DwarfUnit::createAndAddDIE(unsigned int, llvm::DIE&, llvm::DINode const*) 46.34 MB 5.0% 189810 llvm::DwarfCompileUnit::construc...

...; we call SPCU->addType(Arg, ATy), where Arg does not belong to SPCU. >>>> 2> inlined_subroutine constructed in DwarfDebug when adding attribute >>>> abstract_origin >>>> The inlined_subroutine does not belong to the CU we call >>>> addDIEEntry on. >>>> We create the children of inlined_subroutine and call addDIEEntry >>>> before we add it to an owner. >>>> 3> ... >>>> >>>> When building xalan with "lto -g", I saw 3158 violations of the >>>> ass...

...>>>>>>>>> >>>>>>>>>> computeSizeAndOffset takes an offset that is relative to the >>>>>>>>>> start of the CU and returns the offset relative to the CU after laying out >>>>>>>>>> the DIE. >>>>>>>>>> The initial offset before laying out the CU DIE is the header >>>>>>>>>> size, EndOffset will be the offset relative to the CU after laying out the >>>>>>>>>> whole CU DIE. >>>>>>...

...gt;>> >>>>>>>>> >>>>>>>>> computeSizeAndOffset takes an offset that is relative to the start >>>>>>>>> of the CU and returns the offset relative to the CU after laying out the >>>>>>>>> DIE. >>>>>>>>> The initial offset before laying out the CU DIE is the header >>>>>>>>> size, EndOffset will be the offset relative to the CU after laying out the >>>>>>>>> whole CU DIE. >>>>>>>>>...

...formal_parameter constructed in DwarfDebug when adding attribute type we call SPCU->addType(Arg, ATy), where Arg does not belong to SPCU. 2> inlined_subroutine constructed in DwarfDebug when adding attribute abstract_origin The inlined_subroutine does not belong to the CU we call addDIEEntry on. We create the children of inlined_subroutine and call addDIEEntry before we add it to an owner. 3> ... 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 I stated earlier,...

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

Hi, I am working on an issue where a subprogram created here is having abstract_origin pointing to nowhere. DIE *DwarfDebug::updateSubprogramScopeDIE(CompileUnit *SPCU, const MDNode *SPNode) { DIE *SPDie = SPCU->getDIE(SPNode); assert(SPDie && "Unable to find subprogram DIE!"); DISubprogram SP(SPNode); // If we're updating an abstra...

...ut a month now. Here's what happens when I attempt to use gdb to debug one of my programs on OS X: > > gdb stack crawl at point of internal error: > [ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin (align_down+0x0) [0x122300] > [ 1 ] /usr/libexec/gdb/gdb-i386-apple-darwin (find_partial_die_in_comp_unit+0x65) [0xc0e19] > [ 2 ] /usr/libexec/gdb/gdb-i386-apple-darwin (find_partial_die+0x2d4) [0xcf07f] > [ 3 ] /usr/libexec/gdb/gdb-i386-apple-darwin (fixup_partial_die+0x29) [0xcf0b3] > [ 4 ] /usr/libexec/gdb/gdb-i386-apple-darwin (scan_partial_symbols+0x26) [0xcf9e7] > [ 5 ] /...

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 meaningless to me. -- -...

...gt;>>>>>> >>>>>>>> >>>>>>>> computeSizeAndOffset takes an offset that is relative to the start >>>>>>>> of the CU and returns the offset relative to the CU after laying out the >>>>>>>> DIE. >>>>>>>> The initial offset before laying out the CU DIE is the header size, >>>>>>>> EndOffset will be the offset relative to the CU after laying out the whole >>>>>>>> CU DIE. >>>>>>>> We can think of...

...his issue. >>>>>>>> >>>>>>> >>>>>>> computeSizeAndOffset takes an offset that is relative to the start >>>>>>> of the CU and returns the offset relative to the CU after laying out the >>>>>>> DIE. >>>>>>> The initial offset before laying out the CU DIE is the header size, >>>>>>> EndOffset will be the offset relative to the CU after laying out the whole >>>>>>> CU DIE. >>>>>>> We can think of EndOffset as th...

...been broken for about a month now. Here's what happens when I attempt to use gdb to debug one of my programs on OS X: gdb stack crawl at point of internal error: [ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin (align_down+0x0) [0x122300] [ 1 ] /usr/libexec/gdb/gdb-i386-apple-darwin (find_partial_die_in_comp_unit+0x65) [0xc0e19] [ 2 ] /usr/libexec/gdb/gdb-i386-apple-darwin (find_partial_die+0x2d4) [0xcf07f] [ 3 ] /usr/libexec/gdb/gdb-i386-apple-darwin (fixup_partial_die+0x29) [0xcf0b3] [ 4 ] /usr/libexec/gdb/gdb-i386-apple-darwin (scan_partial_symbols+0x26) [0xcf9e7] [ 5 ] /usr/libexec/gdb/gdb-...

.... > Here's what happens when I attempt to use gdb to debug one of my programs on > OS X: > > gdb stack crawl at point of internal error: > [ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin (align_down+0x0) [0x122300] > [ 1 ] /usr/libexec/gdb/gdb-i386-apple-darwin > (find_partial_die_in_comp_unit+0x65) [0xc0e19] > [ 2 ] /usr/libexec/gdb/gdb-i386-apple-darwin (find_partial_die+0x2d4) > [0xcf07f] > [ 3 ] /usr/libexec/gdb/gdb-i386-apple-darwin (fixup_partial_die+0x29) > [0xcf0b3] > [ 4 ] /usr/libexec/gdb/gdb-i386-apple-darwin (scan_partial_symbols+0x26) > [0xcf9e...