similar to: [LLVMdev] context/scope of instruction

Am 20.01.2012 um 18:12 schrieb Devang Patel: > > On Jan 19, 2012, at 10:12 AM, Christian Jacobs wrote: > >> Hello, >> I need to know how I get the LLVM::IDScope object of an instruction. >> >> My program contains: >> call void (...)* @commit(), !dbg !16 >> >> !16 = metadata !{i32 16, i32 5, metadata !8, null} >> >> !8 = metadata

On Jan 19, 2012, at 10:12 AM, Christian Jacobs wrote: > Hello, > I need to know how I get the LLVM::IDScope object of an instruction. > > My program contains: > call void (...)* @commit(), !dbg !16 > > !16 = metadata !{i32 16, i32 5, metadata !8, null} > > !8 = metadata !{i32 589835, metadata !4, i32 10, i32 1, metadata !2, i32 0} ; [ DW_TAG_lexical_block ] > !8

Hi, For my project, I am using internal llvm class functions to print the filename and directory associated with an instruction from the debug information. With a recent checkout of llvm and clang (svn revision 129445), the following custom code (e.g. in a pass that prints directory info for all instructions) returns the filename iso. directory whenever Scope refers to a lexical block: if (const

Hello, The documentation for debug information (http://llvm.org/docs/SourceLevelDebugging.html) says the structure of block descriptors metadata is: !3 = metadata !{ i32, ;; Tag = 11 + LLVMDebugVersion (DW_TAG_lexical_block) metadata,;; Reference to context descriptor i32, ;; Line number i32 ;; Column number } However, looking at the generated metadata, there are 2 extra

Hi John, On Thu, Nov 5, 2009 at 8:43 AM, John Criswell <criswell at uiuc.edu> wrote: > Does the debug facilities in LLVM TOT, at present, maintain information > better than LLVM 2.6 (i.e., if a front-end puts the debug information in, > will the optimizations not take it out)?  Does the information that the > llvm-gcc front-end adds comparable to what llvm-gcc in LLVM 2.6 does?

----- Original Message ----- > On Sat, Jul 20, 2013 at 9:15 PM, Chris Lattner <clattner at apple.com> > wrote: > > Sorry, just getting caught up on an old thread. I haven't been > > involved in discussions of this. > > > > On Jul 17, 2013, at 8:53 AM, Bob Wilson <bob.wilson at apple.com> > > wrote: > >> First, let me try to clarify my

I'm running into a problem with generating debugging information that I'm not sure how to debug; I'd be happy to have some suggestions about where to start digging in. In short, I believe that I'm correctly generating debug info (with DIBuilder, which has so far been quite nice!), and a scan of the meta-data in the IR looks generally right. However, if I run dwarfdump on my

I'm trying to write a llvm pass to add debug info into a non-debug-info bitcode file. I have been read http://llvm.org/docs/SourceLevelDebugging.html. And I use DIBuilder to produce the debug metadata. I know I can't get all information form ir code . So I add some manual info as test data. After executing my pass, I can find debug info metadata in my generated bitcode. Those metadata

Here are some issues that I am unclear about. What would be great is if the answers could be incorporated into the comments and documentation for DIFactory and DebugInfo.h: 1) What types of DIScope are valid arguments for DebugLoc::get()? The method takes an MDNode* argument, so looking at the function signature is no help. For example, DIFile is a subtype of DIScope, however looking at

Hello Everyone, I need to have your thoughts on this. Consider the following test case -- ------------------------------------------- 1 int main(int Argc, char **Argv) { 2 int Local = 6; 3 printf("%d\n",Local); 4 5 { 6 printf("%d\n",Local); 7 int Local = 7; 8 printf("%d\n",Local); 9 }

Oh, I see. Sorry I misunderstood. I'll try to come up with some minimal IR. The assertion stems from the fact that getCompileUnitDIE() returns null and then crashes at DWARFUnit.cpp:301. I admit I don't know if this problem is on the parsing or the generation side. While I come up with the IR, basically what I was doing was using a DebugLoc with scope being a DIFile rather than a

Hi David, OK, I got that DIE in Compile Unit scope may point to a DIE in subprogram scope. But how about that we are emitting a subprogram entry that has no attributes? 0x0000002b: DW_TAG_subprogram [3] * 0x0000002c: DW_TAG_typedef [4] DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => {0x00000040}) DW_AT_name [DW_FORM_strp] (

Hi Sourabh, Thanks for raising this issue. To answer your question, (afaik) there isn’t anyone working on DW_AT_start_scope support in tree. We’re looking for a solution to this problem for Swift debugging, where it's important not to make a debug location for a variable available until its (guaranteed) initialization is complete. If at all possible, I’d /much/ rather we use the existing

>From a thread with Adrian on llvm-commits I looked a little at cases where DwarfCompileUnit's getOrCreateContextDIE's "fallback to return the CU" didn't fire when a CU DIE was required (ie: when the "getDIE" call actually found the CU before the fallback happened) This seems unnecessary, and any case where we do this (where a metadata node has a non-null

I figured out my previous problem with DIBuilder. However, now I can't seem to get the compiler to emit location information for local variables. Here's how my IR looks: --- define i32 @"\01_main"() { init: %exception1 = alloca i8* %0 = alloca i32 %"bar:Int32" = alloca i32 %1 = alloca i32 %2 = alloca i32* br label %code code:

#define GET_BIT(lll) \ // blah blah #define G(label1,label2) \ { \ // decent amount code \ ... while (1) { \ GET_BIT(label2); \ }; \ } void f() { if (..) G('c', 'd'); while ( .. ) G('a','b'); } After perf sampling, a lot

Hi,   My problem definition is to collect "end line" for each scope (i.e. start and end line for a scope). I need to dump this information while emitting target code for an architecture. Though I understand that scoping details are not modeled in LLVM. Reference: http://llvm.org/docs/SourceLevelDebugging.html#format_common_lifetime   There are 2 classes I am referring, viz, DIScope and

Sorry, I didn't have a small IR example and I was sure I was just doing something stupid. Thanks for the help, I'll try it out and report back. Maybe it would be good to add an assertion or something that tells people what's wrong in this case, since the generated DWARF seems to be invalid? On Wed, Aug 13, 2014 at 5:53 PM, David Blaikie <dblaikie at gmail.com> wrote: > Use

I found the problem. The llvm.dbg.declare call must have a !dbg tag, otherwise the location info is not generated. Changing the invocation in my original example to "call void @llvm.dbg.declare(metadata !{i32* %"bar:Int32"}, metadata !13), !dbg !16" causes MC to generate the local location as expected. -Joe On Thu, Dec 29, 2011 at 12:41 PM, Joe Groff <arcata at

That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_subroutine may refer