search for: debuginfofind

...#1: tid = 0xbebaf, 0x000000010c5f6dc1 clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP frame #0: 0x000000010c5f6dc1 clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161 frame #1: 0x000000010c5147df clang`llvm::DebugInfoFinder::processSubprogram(llvm::DISubprogram) + 47 frame #2: 0x000000010c514701 clang`llvm::DebugInfoFinder::processType(llvm::DIType) + 817 frame #3: 0x000000010c5145f3 clang`llvm::DebugInfoFinder::processType(llvm::DIType) + 547 frame #4: 0x000000010c514695 clang`llvm::DebugInfoFinder::pro...

...= 0xbebaf, 0x000000010c5f6dc1 clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP > frame #0: 0x000000010c5f6dc1 clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161 > frame #1: 0x000000010c5147df clang`llvm::DebugInfoFinder::processSubprogram(llvm::DISubprogram) + 47 > frame #2: 0x000000010c514701 clang`llvm::DebugInfoFinder::processType(llvm::DIType) + 817 > frame #3: 0x000000010c5145f3 clang`llvm::DebugInfoFinder::processType(llvm::DIType) + 547 > frame #4: 0x000000010c514695 clang`llvm::DebugInf...

...baf, 0x000000010c5f6dc1 clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP >> frame #0: 0x000000010c5f6dc1 clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161 >> frame #1: 0x000000010c5147df clang`llvm::DebugInfoFinder::processSubprogram(llvm::DISubprogram) + 47 >> frame #2: 0x000000010c514701 clang`llvm::DebugInfoFinder::processType(llvm::DIType) + 817 >> frame #3: 0x000000010c5145f3 clang`llvm::DebugInfoFinder::processType(llvm::DIType) + 547 >> frame #4: 0x000000010c514695 clang`llvm:...

...lang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161, queue = > 'com.apple.main-thread, stop reason = signal SIGSTOP > >> frame #0: 0x000000010c5f6dc1 > clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161 > >> frame #1: 0x000000010c5147df > clang`llvm::DebugInfoFinder::processSubprogram(llvm::DISubprogram) + 47 > >> frame #2: 0x000000010c514701 > clang`llvm::DebugInfoFinder::processType(llvm::DIType) + 817 > >> frame #3: 0x000000010c5145f3 > clang`llvm::DebugInfoFinder::processType(llvm::DIType) + 547 > >> frame #4: 0x000...

...st*) + 161, queue = >> >> 'com.apple.main-thread, stop reason = signal SIGSTOP >> >> frame #0: 0x000000010c5f6dc1 >> >> clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161 >> >> frame #1: 0x000000010c5147df >> >> clang`llvm::DebugInfoFinder::processSubprogram(llvm::DISubprogram) + 47 >> >> frame #2: 0x000000010c514701 >> >> clang`llvm::DebugInfoFinder::processType(llvm::DIType) + 817 >> >> frame #3: 0x000000010c5145f3 >> >> clang`llvm::DebugInfoFinder::processType(llvm::DIType) + 5...

...>> >> 'com.apple.main-thread, stop reason = signal SIGSTOP > >> >> frame #0: 0x000000010c5f6dc1 > >> >> clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161 > >> >> frame #1: 0x000000010c5147df > >> >> clang`llvm::DebugInfoFinder::processSubprogram(llvm::DISubprogram) + > 47 > >> >> frame #2: 0x000000010c514701 > >> >> clang`llvm::DebugInfoFinder::processType(llvm::DIType) + 817 > >> >> frame #3: 0x000000010c5145f3 > >> >> clang`llvm::DebugInfoFinder::proc...

...; 'com.apple.main-thread, stop reason = signal SIGSTOP >> >> >> frame #0: 0x000000010c5f6dc1 >> >> >> clang`llvm::SmallPtrSetImpl::insert_imp(void const*) + 161 >> >> >> frame #1: 0x000000010c5147df >> >> >> clang`llvm::DebugInfoFinder::processSubprogram(llvm::DISubprogram) + >> >> >> 47 >> >> >> frame #2: 0x000000010c514701 >> >> >> clang`llvm::DebugInfoFinder::processType(llvm::DIType) + 817 >> >> >> frame #3: 0x000000010c5145f3 >> >> >...

...y having verification in two places (IR verifier and the module pass). The advantage is we can verify more frequently on structures, comparing against doing this in the module pass. > > b) Module pass - > > Walk down from the CUs in the file and verify everything we see. > This is DebugInfoFinder.processModule. > I think then the only duplication we'll get are methods from classes as > the context for functions. We'll also need to check the contexts on the > various metadata operands on the line numbers which is unfortunate as that > probably involves a separate walk...

I am using the trunk version of llvm-gcc to generate the debug info, and I have checked out the DebugInfoFinder class. Basically, I am interested in looking up debug info for structures, and I am wondering if there is a way for me to look up the debug info associated with a Type * directly instead of building a custom map from Type * to DICompositeType by iterating through the type iterator in DebugIn...

Folks, I am newbie to llvm! I am writing a simple pass that inherits from ModulePass. I override the runOnModule method. In the method, i am attempting to print all the function in the module and the source-file they appear in. I could print the name of the function using the Module::iterator. I am, however, not able to figure-out the way to identify the source-file for a given

..."dbg"); > if (MDNode *Dbg = I->getMetadata(dbgKind)) { > ... > Thanks! This appears to work. I also have code that looks up debug information for GlobalVariables and regular LLVM Value *'s. For the former, I think I can look up their debug information by using the DebugInfoFinder class and iterating through all the MDNodes for global variables (using the global_variable_begin()/global_variable_end() methods). Is this the best way to do it, or is there a better way? For LLVM Value *s, I'm not sure how to get the debug information if they come from alloca instruct...

In general I use DebugInfoFinder and clear out Metadata if GV in null or GV->isDeclaration(). If there is any interest, I can post that patch... Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: Tobias Edler von Koch [mai...

...removed. Is this an intended change? Yes, I'll update the doc. We were relying in the existence of this node, and things broke once we switched from LLVM 2.8 to 3.0. Is there an alternative location where all the subprogram debug descriptors (DW_TAG_subprogram) can be obtained? You can use DebugInfoFinder from DebugInfo.h. It provides an iterator to walk over all subprograms. - Devang --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any re...

My off the cuff idea here is to make it a module pass, but we'll split the verification a bit: a) IR verification time - Verify debug metadata attached to instructions (i.e. line information). Only check it for structure (i.e. do the various metadata nodes have the right number and kind of operands). b) Module pass - Walk down from the CUs in the file and verify everything we see. I think

Hi all, I am wondering if someone can give me pointers to how to use the DI* classes defined in DebugInfo.h. In particular, I am confused about how to get a MDNode from the GlobalVariable's that hold the debug info so that they can be passed into the DI* classes, and the difference between MDNode and NamedMDNode in general. Thanks for your help. Alvin

On Mon, Sep 21, 2009 at 9:34 PM, Alvin Cheung <alvin.cheung at gmail.com> wrote: > Hi all, > > I am wondering if someone can give me pointers to how to use the DI* classes > defined in DebugInfo.h.  In particular, I am confused about how to get a MDNode > from the GlobalVariable's that hold the debug info so that they can be passed > into the DI* classes, Now, MDNode

...Is this an intended change? Yes, I'll update the doc. > We were relying in the existence of this node, and things broke once we switched from LLVM 2.8 to 3.0. > Is there an alternative location where all the subprogram debug descriptors (DW_TAG_subprogram) can be obtained? You can use DebugInfoFinder from DebugInfo.h. It provides an iterator to walk over all subprograms. - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120209/2bd23e72/attachment.html>

...truction came from (with a view to attaching an identifying DW_TAG to it)? I've found the tag definitions in include/llvm/Support/Dwarf.h and added my own. lib/CodeGen/AsmPrinter/DwarfDebug.cpp seems to be the only place that emits dwarf data into the assembly stream. It also seems to create a DebugInfoFinder which accesses the IR instructions. Thanks for any pointers that might slow my spinning head down, rw -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100824/98e6238e/attachment.html>

...e? > > 2) DebugLoc has a getAsMDNode() method, but apparently it's only > available for Instructions? > > 3) How can I retrieve a DIType instance? I can't find a way to obtain a > MDNode for a Type... ? > > Many thanks if somebody can shed some light on this. See DebugInfoFinder interface in Analysis/DebugInfo.h - Devang

Hi all, Currently, debug info verifier is part of the IR verifier which is a function pass. One part of the IR verifier that I don't like is it verifies module-level data in doFinalization. If we have two verifier passes in a single module pass manager, doFinalization of the two passes will run on the same module data after all passes. I followed the same model for debug info verifier: