search for: dwarfdebug

...failures in llvm::DbgVariable::addMMIEntry: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/1816/steps/check-msan%20in%20gcc%20build/logs/stdio I did not find the offender yet. Any ideas? clang-5.0: /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h:131: void llvm::DbgVariable::addMMIEntry(const llvm::DbgVariable&): Assertion `V.Var == Var && "conflicting variable"' failed. clang-5.0: /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h:131: void llvm::DbgVariable::addMMIE...

...gt;> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/ >> builds/1816/steps/check-msan%20in%20gcc%20build/logs/stdio >> I did not find the offender yet. Any ideas? >> >> clang-5.0: /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h:131: void llvm::DbgVariable::addMMIEntry(const llvm::DbgVariable&): Assertion `V.Var == Var && "conflicting variable"' failed. >> clang-5.0: /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h:131: void llvm::DbgVariable...

>From DwarfDebug.cpp: >/// GetOrCreateSourceID - Look up the source id with the given directory and >/// source file names. If none currently exists, create a new id and insert it >/// in the SourceIds map. This can update DirectoryNames and SourceFileNames >/// maps as well. >unsigned DwarfDebug::G...

Josh Matthews wrote: >> From DwarfDebug.cpp: > >> /// GetOrCreateSourceID - Look up the source id with the given directory and >> /// source file names. If none currently exists, create a new id and insert it >> /// in the SourceIds map. This can update DirectoryNames and SourceFileNames >> /// maps as well. &g...

...e not terribly hard to work out how the paths are different. Good luck, --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Martin J. O'Riordan via llvm-dev Sent: Monday, September 25, 2017 7:56 AM To: 'LLVM Developers' Subject: [llvm-dev] Assertion in 'DwarfDebug.cpp' Since updating to the LLVM v5.0 Final tag, I am seeing a crash when I enable '-g'. With a Debug build this hits an assertion at line #923 in 'lib/CodeGen/AsmPrinter/DwarfDebug.cpp': assert(EndLabel && "Forgot label after instruction ending a range!"); T...

Since updating to the LLVM v5.0 Final tag, I am seeing a crash when I enable '-g'. With a Debug build this hits an assertion at line #923 in 'lib/CodeGen/AsmPrinter/DwarfDebug.cpp': assert(EndLabel && "Forgot label after instruction ending a range!"); The values of related variables at this time are: 'Begin' is: DBG_VALUE %I23, %noreg, !"fp", <!345>; line no:381 'End' is: DBG_VALUE %I19, 88, !"...

...6.7%+15.6%=22.3% of the the total allocated memory? > If I understand correctly the numbers, this does not tell anything about how much the Dwarf emitter accounts on the *peak memory* usage (could be more, could be nothing...). I think these nodes represent allocations from the DWARF emitter: DwarfDebug::DwarfDebug 9.5% DwarfDebug::endFunction 15.6% DIEValueList::addValue 9.1% total 34.2% I believe they are totals, but my reading of the code is that the DWARF emitter does not deallocate its memory until the end of code generation, so total ~= peak in this case. I am not surprised by these figure...

...ated dbg.declare intrinsic, declaring the same fragment twice. The duplicated call was generated by the jump threading pass. I have a patch (see below) that removes simply such duplicates, but I'm not sure whether that is the right approach. Cheers, Björn diff --git a/lib/CodeGen/AsmPrinter/DwarfDebug.cpp b/lib/CodeGen/AsmPrinter/DwarfDebug.cpp index 499780a173b..308b6bd2b9f 100644 --- a/lib/CodeGen/AsmPrinter/DwarfDebug.cpp +++ b/lib/CodeGen/AsmPrinter/DwarfDebug.cpp @@ -220,6 +220,13 @@ ArrayRef<DbgVariable::FrameIndexExpr> DbgVariable::getFrameIndexExprs() const { return...

...bit of a chat about it. I've tested simple cases of a single type and they seem to work OK. Multiple types from the same translation unit won't work at the moment due to the MC issue. The practical details are fairly simple. When CompileUnit goes to create a type, first it hands it off to DwarfDebug to decide whether it's going to be in a type unit. If it is, DwarfDebug spins up a new CompileUnit that's really a type unit, emits the type into that unit (creating all dependent types and other paraphernalia), attaches the signature (using the ODR hash as a stand-in for now) and offset to...

...The first patch adds support for ref_addr. Most of it is from r176882, but instead of always using an integer for ref_addr, we use label + offset for relocation on non-darwin platforms. The second patch is a modified version of r191792. The main change is to use a single map instead of 3 maps in DwarfDebug and instead of calling DwarfDebug::getDIE|insertDIE directly, we delegate the function calls to DwarfDebug from CompileUnit. No testing case is added in the 1st patch, since the compiler does not use ref_addr yet. For the 2nd patch, testing cases are updated to make sure we remove duplicated DIEs...

...Patel <dpatel at apple.com> wrote: > Your recent changes mentioned below would change correctness of debug info, > but it would unlikely to impact structure of DWARF generated. And somehow, > this structure is invalid in your case. I was hoping for a quick-fix on the assumptions of DwarfDebug about Subprograms' MDNodes, but it might be anywhere. Reducing the test case is the best solution, but it might not be easy. Validating the MDNodes in DIFactory (or anywhere before DwarfDebug) would be a good step to ensure IR consistency and isolate problems. Unfortunately, it is the kind of...

DW_AT_stmt_list attribute's value is a section offset to the line no info for current compilation unit. If there is only one compilation unit generated per .o file then it is always zero. What kind of errors are you seeing ? - Devang On Tue, Jun 29, 2010 at 9:02 AM, Artur Pietrek <pietreka at gmail.com> wrote: > Hi all, > While implementing debug info for our backend, we've

I updated DwarfDebug to use section offset, instead of hard coding 0, to handle LTO properly. r107202. Thanks for brining this up. - Devang On Tue, Jun 29, 2010 at 11:27 AM, Devang Patel <devang.patel at gmail.com> wrote: > DW_AT_stmt_list attribute's value is a section offset to the line no > info fo...

...begin-.Lsection_line ## DW_AT_stmt_list and that will be evaluated by assembler to a constant. It has to be a label, not a constant, because it is the linker who knows the correct offset. Artur On Tue, Jun 29, 2010 at 10:18 PM, Devang Patel <devang.patel at gmail.com>wrote: > I updated DwarfDebug to use section offset, instead of hard coding 0, > to handle LTO properly. > r107202. > > Thanks for brining this up. > - > Devang > > On Tue, Jun 29, 2010 at 11:27 AM, Devang Patel <devang.patel at gmail.com> > wrote: > > DW_AT_stmt_list attribute's value...

Hi all, I'm using my own front-end that generates LLVM debug info metadata. I was using LLVM 2.9 debug version and I'm moving to LLVM 3.2 debug version of metadata. On my example I got llc 3.2 to fail on following assertion: llc: /work1/tools/llvm/3.2/sources/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1471: void llvm::DwarfDebug::endFunction(const llvm::MachineFunction*): Assertion `TheCU && "Unable to find compile unit!"' failed. 0 llc 0x0000000000ffb43f 1 llc 0x0000000000ffd6ba 2 libpthread.so.0 0x00007f5dd70238f0 3 libc.so.6 0x00007f...

Hi, Thanks for the pointer. I am unfortunately running into llc problems with this pass. I did *opt -debug-ir hello.bc -o hello.deb.bc* *llc -march=arm -debug -O0 hello.deb.bc -o hello.deb.s* This is aborting with the error: llc: llvm-3.4/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1614: void llvm::DwarfDebug::beginFunction(const llvm::MachineFunction*): Assertion `TheCU && "Unable to find compile unit!"' failed. I'm assuming this is because llc found some errors in the metadata that debug-ir prints out. How do I find and correct this? Thanks ag...

...>> If I understand correctly the numbers, this does not tell anything > about how much the Dwarf emitter accounts on the *peak memory* usage (could > be more, could be nothing...). > > > > I think these nodes represent allocations from the DWARF emitter: > > > > DwarfDebug::DwarfDebug 9.5% > > DwarfDebug::endFunction 15.6% > > DIEValueList::addValue 9.1% > > total 34.2% > > > > I believe they are totals, but my reading of the code is that the DWARF > > emitter does not deallocate its memory until the end of code generation, > &g...

...n I have debug symbols enabled (“-g”), I get the following error when Clang generates the Dwarf info (using a very recent build of LLVM/Clang from Git mirror): > Assertion failed: (TheCU && "Unable to find compile unit!"), function beginFunction, file ../lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1617. > 0 clang-3.4 0x0000000103ff3808 llvm::sys::PrintStackTrace(__sFILE*) + 40 > 1 clang-3.4 0x0000000103ff3c64 SignalHandler(int) + 388 > 2 libsystem_platform.dylib 0x00007fff8dd185aa _sigtramp + 26 > 3 libsystem_platform.dylib 000000000000...

...0x00000000016a43a6 llvm::DwarfUnit::addString(llvm::DIE&, llvm::dwarf::Attribute, llvm::StringRef) + 22 4 clang 0x00000000016c2003 llvm::DwarfCompileUnit::applyVariableAttributes(llvm::DbgVariable const&, llvm::DIE&) + 915 5 clang 0x000000000168bdfe llvm::DwarfDebug::finishVariableDefinitions() + 270 6 clang 0x0000000001690424 llvm::DwarfDebug::finalizeModuleInfo() + 52 7 clang 0x000000000169c4a8 llvm::DwarfDebug::endModule() + 40 8 clang 0x00000000016850f7 llvm::AsmPrinter::doFinalization(llvm::Module&) + 551 9 clang...

Hi all, While implementing debug info for our backend, we've noticed a problem with debug_line section. We believe that the following code is wrong: // DW_AT_stmt_list is a offset of line number information for this // compile unit in debug_line section. It is always zero when only one // compile unit is emitted in one object file. addUInt(Die, dwarf::DW_AT_stmt_list, dwarf::DW_FORM_data4,