similar to: [LLVMdev] getting source-level debug info

>> There are a couple of references made to %llvm.dbg.variable, which >> isn't defined anywhere. It it an intrinsic? A global? Could it be a >> relic from the old debug info docs (where it *is* defined?). The same >> goes for llvm.dbg.derivedtype and llvm.dbg.subrange which are also >> referenced but not defined. > > It was a stale reference. I fixed the

On Feb 1, 2011, at 3:58 AM, Eli Bendersky wrote: > Hello > I'm reading http://llvm.org/docs/SourceLevelDebugging.html and some > things aren't clear. > > There are a couple of references made to %llvm.dbg.variable, which > isn't defined anywhere. It it an intrinsic? A global? Could it be a > relic from the old debug info docs (where it *is* defined?). The same

I want to emit a ref parameter (ie i32*) as if it was i32 in debug info, however when I emit it with llvm.debug.declare referring to the parameter register it shows the actual pointer value of the debug register, instead of the value it refers to. This works fine if the llvm.debug.declare points to a local alloca, how can this be and how can I make it work so both show the integer value

Hello I'm reading http://llvm.org/docs/SourceLevelDebugging.html and some things aren't clear. There are a couple of references made to %llvm.dbg.variable, which isn't defined anywhere. It it an intrinsic? A global? Could it be a relic from the old debug info docs (where it *is* defined?). The same goes for llvm.dbg.derivedtype and llvm.dbg.subrange which are also referenced but not

Could you provide the complete example (with all the necessary metadata to reproduce)? Possible LLVM has a special case for arguments, I'm not sure/don't recall off hand, but can poke around at it & see if there's a reasonable logic to it. On Tue, Dec 20, 2016 at 10:43 PM Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I want to emit a ref parameter (ie

Hi, I had a problem with LLVM not emitting local variable info, even though I had calls to llvm.dbg.define. After some tracking I found that the llvm.dbg.declare (and probably value too) have to have a !dbg !nr after them to get emitted at all. maybe someone can adjust http://llvm.org/docs/SourceLevelDebugging.html#format_common_declare that the two llvm.dbg. functions need a !dbg line info

https://gist.github.com/carlokok/77010598f81e8167592e593ec6c715a1 If needed I can strip it down more tomorrow, but only elements entry point and the two meh methods are used. On December 21, 2016 8:27:12 PM GMT+01:00, David Blaikie <dblaikie at gmail.com> wrote: >Could you provide the complete example (with all the necessary metadata >to >reproduce)? > >Possible LLVM has a

When compiling code with lld -O0 --lto-O0 --eh-frame-hdr I get strange interleaved line info all over the place: ... 0x00000000000595ac 22 11 1 0 0 is_stmt 0x00000000000595bc 25 7 1 0 0 is_stmt <<< 0x00000000000595c0 22 11 1 0 0 is_stmt 0x00000000000595c4 25 7 1 0 0 is_stmt <<< 0x00000000000595c8 26 7 1 0 0 is_stmt but the code only has 1 reference to line 25 and the

On Mar 6, 2012, at 5:31 AM, Seb <babslachem at gmail.com> wrote: > Hi all, > > Anyone have ideas/info on this topic ? > Thanks > Seb > > 2012/3/2 Seb <babslachem at gmail.com> > Hi all, > > I'm using my own front-end to generate following code .ll file targeting x86 32-bit: > > ; ModuleID = 'check.c' > target datalayout =

On Jul 27, 2012, at 2:35 AM, Carlo Kok <ck at remobjects.com> wrote: > Hi, > > I had a problem with LLVM not emitting local variable info, even though > I had calls to llvm.dbg.define. After some tracking I found that the > llvm.dbg.declare (and probably value too) have to have a !dbg !nr after > them to get emitted at all. maybe someone can adjust >

Hi! I created a bug report (https://llvm.org/bugs/show_bug.cgi?id=23712) for this failure but then I realized that my approach may be wrong. The following D source contains a lazy variable: void bar(lazy bool val) { val(); } The lazy variable val is translated to a delegate. The signature and the first IR lines are: define void @_D7opover23barFLbZv({ i8*, i1 (i8*)* } %val_arg) #0 {

On Tue, Jan 5, 2016 at 6:59 PM, Adrian Prantl <aprantl at apple.com> wrote: > Thanks for the clarification, Paul! > Keno, just a few more questions for my understanding: > > > - Indicating that a value changed at source level (e.g. because an > > assignment occurred) > > This is done by a key call. Correct > > - Indicating that the same

Hi, I've recently run into a problem of missing !dbg metadata after the code has been optimized (even opt -O1). The original code was generated using llvmlite python package and I've verified that all instructions have their !dbg metadata present. After optimizing the module (even opt -O1) I see that some instructions (~25%) don't have any dbg metadata. These are mostly getelementptr

I am trying to locate instructions in an LLVM Pass by line and column number (reported by an third-party tool) to instrument them. To achieve this, I am compiling my source files with `clang -g -O0 -emit-llvm` and looking for the information in the metadata using this code: const DebugLoc &location = instruction->getDebugLoc(); // location.getLine() // location.getCol()

Hi all, Anyone have ideas/info on this topic ? Thanks Seb 2012/3/2 Seb <babslachem at gmail.com> > Hi all, > > I'm using my own front-end to generate following code .ll file targeting > x86 32-bit: > > ; ModuleID = 'check.c' > target datalayout = >

Hi all, I'm using my own front-end to generate following code .ll file targeting x86 32-bit: ; ModuleID = 'check.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i386-pc-linux-gnu" @.str581 = internal constant [52 x i8] c"---- test number %d

I think probably the simplest answer is that dbg.declare documents that it must point to an alloca ("This intrinsic provides information about a local element (e.g., variable). The first argument is metadata holding the alloca for the variable. ") - so it's probably best not to think too hard about what it does when that criteria is not met.

I'm going to show the same function, first normally, and then as a coroutine, and show how gdb can see the variable when it's a normal function, but not when it's a coroutine. I'd like to understand if this can be improved. I'm trying to debug a real world problem, but the lack of debug info on variables in coroutines is making it difficult. Should I file a bug? Is this a

I will be out of the office on January 7th and will return on January 19th. I will not have access to email during this time. Please contact Karen Lavelle at klavelle at rice.edu or 713-348-2062 if you have any questions or concerns. Best regards, Annepha On Jan 6, 2016, at 3:58 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Jan 5, 2016, at 10:37 AM,

Adrian had proposed the following staging: 1. Remove offset argument from dbg.value 2. Unify dbg.value and dbg.declare 3. Full implementation I'm not yet sure what to do about the difference in dbg.declare semantics. For example, i think the following currently works ``` top: %x = alloca br else if: dbg.declare(%x... unreachable else: # dbg.declare still applies here ``` I think it would