search for: setcurrentdebuglocation

(2) cause CFI instructions not to emit any .loc directives; done in r289256, plus r289288 (3) file a bug to have someone audit LoopVectorizer.cpp to see whether it is using SetCurrentDebugLocation in the right places; haven't done that part yet (4) reapply my "line 0" patch, which will be the 3rd attempt. r289468 Please ping me when you do (4). Also, will there be a flag to disable this new functionality? I've make '-use-unknown-locations' into a 3-way option, you...

...them. > > > > I propose we do 4 things: (1) commit the patch in SanitizerCoverage.cpp > that you found; > done r288568. > (2) cause CFI instructions not to emit any .loc directives; (3) file a bug > to have someone audit LoopVectorizer.cpp to see whether it is using > SetCurrentDebugLocation in the right places; (4) reapply my "line 0" patch, > which will be the 3rd attempt. > Please ping me when you do (4). Also, will there be a flag to disable this new functionality? > > > I can do all of these if you like, or you can do the first one and I'll do >...

...at's a separate issue. Regarding "how do we find those problems" this is like "how do we find all the bugs" and what we can do is come up with intelligent approaches to finding where they are likely to hide. For example, one possibility is to audit all the places that call SetCurrentDebugLocation; my grep through llvm/lib found 43 instances, which is not horrible. We can make sure that the SetInsertPoint/SetCurrentDebugLocation sequence is correct in all those places. If we can identify components that do depend on the debug line table (like fuzzer and sanitizers) then running a bunch of...

...e's what my code looks like for setting the debug location (some details removed for clarity): void CodeGenerator::setDebugLocation(const SourceLocation & loc) { if (loc != dbgLocation_ && dbgContext_.isScope()) { dbgLocation_ = loc; if (loc.file == NULL) { builder_.SetCurrentDebugLocation(llvm::DebugLoc()); } else if (loc.file == module_->moduleSource()) { TokenPosition pos = tokenPosition(loc); // ** Comment out this line and the DIE errors disappear ** builder_.SetCurrentDebugLocation( DebugLoc::get(pos.beginLine, pos.beginCol, dbgContext_));...

I'm attempting to get my compiler to use the new APIs for source-level debugging via SetCurrentDebugLocation(). I'm getting a lot of "duplicate symbol" errors in my generated assembly code: ReflectionTest.s:348: Error: symbol `.Lfunc_end6' is already defined ReflectionTest.s:372: Error: symbol `.Lfunc_end6' is already defined ReflectionTest.s:395: Error: symbol `.Lfunc_end6' is...

...setting the debug location (some details > removed for clarity): > > void CodeGenerator::setDebugLocation(const SourceLocation & loc) { > if (loc != dbgLocation_ && dbgContext_.isScope()) { > dbgLocation_ = loc; > if (loc.file == NULL) { > builder_.SetCurrentDebugLocation(llvm::DebugLoc()); > } else if (loc.file == module_->moduleSource()) { > TokenPosition pos = tokenPosition(loc); > // ** Comment out this line and the DIE errors disappear ** > builder_.SetCurrentDebugLocation( > DebugLoc::get(pos.beginLine, pos.beg...

...ooking at lib/Transforms/Instrumentation/SanitizerCoverage.cpp: DebugLoc EntryLoc; if (IsEntryBB) { if (auto SP = F.getSubprogram()) EntryLoc = DebugLoc::get(SP->getScopeLine(), 0, SP); ... } else { EntryLoc = IP->getDebugLoc(); } IRBuilder<> IRB(&*IP); IRB.SetCurrentDebugLocation(EntryLoc); So, using this I assumed that the newly generated instructions have proper debug info, and so far it worked. I wonder if you can re-commit your changes under a flag, off-by default, so that everyone interested can play with it? --paulr From: Kostya Serebryany [mailto:kcc at google.c...

...ng the same thing under Linux, however dwarfdump doesn't segfault on Linux when I feed it my LLVM-generated binary. (It does report errors, however: "dwarf_srclines: DW_DLE_ATTR_FORM_BAD". The weird part is that it does this even when I completely disable the code that calls IRBuilder.SetCurrentDebugLocation()). As per usual, this is with a recent LLVM head (like about a week old). On Tue, Sep 7, 2010 at 9:21 AM, Devang Patel <dpatel at apple.com> wrote: > > On Sep 7, 2010, at 9:11 AM, Renato Golin wrote: > > On 7 September 2010 16:49, Devang Patel <dpatel at apple.com> wrote...

On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: > 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

...der Linux, however dwarfdump doesn't > segfault on Linux when I feed it my LLVM-generated binary. (It does report > errors, however: "dwarf_srclines: DW_DLE_ATTR_FORM_BAD". The weird part is > that it does this even when I completely disable the code that calls > IRBuilder.SetCurrentDebugLocation()). > Interestingly enough, I just upgraded to the latest Ubuntu (10.10 - Maverick Meercat), and the LLVM-generated code no longer builds: I get the following error in the assembler stage (after the bitcode is converted to assembly): SwitchStmtTest.s: Assembler messages: SwitchStmtTest.s...

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

Hello, For some reason, I have to stick on llvm 3.3 for a language compiler, I find that the location debug info is attached to each instruction using !dbg, however, I found some of that information is mis-attched and need to be changed, so I want to *know what functions(I checked all funcs in DIBuilder.h but didn't find a appropriate one) are used to attach those !dbg nodes to each

Talin wrote: > I'm attempting to get my compiler to use the new APIs for source-level > debugging via SetCurrentDebugLocation(). I'm getting a lot of "duplicate > symbol" errors in my generated assembly code: > > ReflectionTest.s:348: Error: symbol `.Lfunc_end6' is already defined > ReflectionTest.s:372: Error: symbol `.Lfunc_end6' is already defined > ReflectionTest.s:395: Error: symb...

On Sun, Nov 29, 2009 at 9:12 AM, Talin <viridia at gmail.com> wrote: > Talin wrote: >> I'm attempting to get my compiler to use the new APIs for source-level >> debugging via SetCurrentDebugLocation(). I'm getting a lot of "duplicate >> symbol" errors in my generated assembly code: >> >> ReflectionTest.s:348: Error: symbol `.Lfunc_end6' is already defined >> ReflectionTest.s:372: Error: symbol `.Lfunc_end6' is already defined >> ReflectionTes...

...(I checked all funcs in DIBuilder.h but didn't find a appropriate one) are used to attach those !dbg nodes to each instruction ? It would be even better if you can points to the places that clang uses to create those nodes. >> > > Have a look at IRBuilder instead: > > void SetCurrentDebugLocation (DebugLoc L) > Set location information used by debugging information. > const DebugLoc & getCurrentDebugLocation () const > Get location information used by debugging information. > > -- adrian > > PS: Isn’t it nice how we consistently name accessor functions? &g...

...(some >> details removed for clarity): >> >> void CodeGenerator::setDebugLocation(const SourceLocation & loc) { >> if (loc != dbgLocation_ && dbgContext_.isScope()) { >> dbgLocation_ = loc; >> if (loc.file == NULL) { >> builder_.SetCurrentDebugLocation(llvm::DebugLoc()); >> } else if (loc.file == module_->moduleSource()) { >> TokenPosition pos = tokenPosition(loc); >> // ** Comment out this line and the DIE errors disappear ** >> builder_.SetCurrentDebugLocation( >> DebugLoc::get(po...

...ng the same thing under Linux, however dwarfdump doesn't segfault on Linux when I feed it my LLVM-generated binary. (It does report errors, however: "dwarf_srclines: DW_DLE_ATTR_FORM_BAD". The weird part is that it does this even when I completely disable the code that calls IRBuilder.SetCurrentDebugLocation()). > > Interestingly enough, I just upgraded to the latest Ubuntu (10.10 - Maverick Meercat), and the LLVM-generated code no longer builds: I get the following error in the assembler stage (after the bitcode is converted to assembly): > > SwitchStmtTest.s: Assembler messages: >...

On Sep 7, 2010, at 9:11 AM, Renato Golin wrote: > On 7 September 2010 16:49, Devang 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

It might be a wider problem than libfuzzer. I did want to raise the problem asap and libfuzzer is something we know has the problem. If it came across as "libfuzzer is evil" that was not my intent, sorry! --paulr From: Kostya Serebryany [mailto:kcc at google.com] Sent: Thursday, December 01, 2016 2:53 PM To: Robinson, Paul Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev]

On 7 September 2010 16:49, Devang 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