search for: dilocalvariables

Hi all, I'm dealing with LLVM's debug information metadata, and have run into an interesting edge case. Under normal circumstances, every `DILocalVariable` has a `User` in the form of the `llvm.dbg.*` intrinsic that produced it. Knowing this, I can go from `DILocalVariable` to `MetadataAsValue`, grab the users, and end up at the corresponding instruction + function. In some cases,

> On Nov 18, 2019, at 8:33 AM, Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > > Hi llvm-dev@, > > Switching focus to the LLVM implementation, the significant change is > using dbg.value's first operand to refer to a DILocalVariable, rather > than a Value. There's some impedance mismatch here, because all the > documentation (for example in the

Hi! Is it valid to assume that the scope for a parameter-describing DILocalVariable always is a DISubprogram? Or do you know of any case where a parameter's scope can be a sub-scope of the DISubprogram? I added a check to the IR verifier and an assertion to DIBuilder::createParameterVariable() that verify this. This resulted in one test case, DebugInfo/X86/double-declare.ll, failing when

What would it look like without this extension? If we modeled it as if all the register values were already on the stack (an extension of the current way where the singular value is modeled as being already on the stack, if I understand it correctly?)? If it's decided that the best approach is to introduce something like DW_OP_LLVM_register - might be worth migrating to that first (basically

I will start from afar… When a dead function argument is removed, should we keep around the debug info for it? I have the following case: define internal fastcc void @foo(i8* %aa, i8* %reg, i8* %field, i32 %bb, ...) unnamed_addr #3 !dbg !28 { entry: call void @llvm.dbg.value(metabb i8* %aa, i64 0, metabb !34, metabb !47), !dbg !57 call void @llvm.dbg.value(metabb i8* %reg, i64 0,

Currently, the debug intrinsic functions each have 3 arguments: an SSA value representing either the address or Value of a local variable, a DILocalVariable, and a complex expression. If the SSA value is an Instruction, and that Instruction is at some point deleted, we attempt to salvage the SSA value by recreating the instruction within the complex expression. If the instruction cannot be

David, Dean, all, The bots got red today with assertion 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

Thanks! On Mon, May 8, 2017 at 6:25 PM, Reid Kleckner <rnk at google.com> wrote: > I give it 99% odds it was r302483. Let's revert and debug it tomorrow. > > On Mon, May 8, 2017 at 6:20 PM, Kostya Serebryany via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> David, Dean, all, >> >> The bots got red today with assertion failures in >>

Hey folks, Would you all mind having a bit of a design discussion around the feature both at the DWARF level and the LLVM implementation? It seems like what's currently being proposed/reviewed (based on the DWARF feature as spec'd) is a pretty big change & I'm not sure I understand the motivation, exactly. The core point of my confusion: Why does describing the thing a pointer

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 {

...local variables. > > It appears that the function is already inlined before > strip-dead-debug-info starts its work. As a result the DICompileUnit is > cleaned and its subprograms list has no reference to the DISubprogram for > the inlined function, but as there is reference from the DILocalVariables > to the DISubprogram it remains (IMHO). > > This caused to a segmentation fault while running llc on the optimized IR > file at function "constructAbstractSubprogramScopeDIE" in file > DwarfDebug.cpp because the scope of the DISubprogram is null (I assume it > should be...

> I don't have a strong opinion on representation. I can see how having a dedicated instruction to model implicit pointers would aid readability & be simpler to document/grok, but perhaps in the future we'll want to support other operations that refer to variable > DIEs. In the short term migrating to an extended dbg.value representation might take more work. Alok, wdyt? Below

David, Peter, Let me try it one more time, now with an example… Short of upstreaming a fake function clone pass, let me only illustrate the issue in raw debug output. Hopefully it should be sufficient. Try this: clang -Os -g -fno-strict-aliasing test_arg_del.ll -mllvm -debug -mllvm -print-after-all After DAE - Removing argument 1 (reg) from foo DAE - Removing argument 2

> On Apr 1, 2020, at 2:56 AM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > > > Do you mean documenting the desired frontend behavior, or adding some verifier in > LLVM? A warning for the latter is that SROA may currently emit IR that contains a > mix of declares and values for different fragments of an aggregate variable, so I > assume that is something that

>As the person who has advocated for DW_OP_LLVM_arg(N) before, my main motivation was to resolve the ambiguity of constant DIExpressions: As a worst-case example: > >dbg.value(%undef, !DILocalVariable(x), DIExpression(DW_OP_constu, 42)) > >Is this undefined, or constant 42? > >But if we make dbg.value fully variadic with all parameters pushed to the stack ahead of time, we can

...inline function with two local variables. It appears that the function is already inlined before strip-dead-debug-info starts its work. As a result the DICompileUnit is cleaned and its subprograms list has no reference to the DISubprogram for the inlined function, but as there is reference from the DILocalVariables to the DISubprogram it remains (IMHO). This caused to a segmentation fault while running llc on the optimized IR file at function "constructAbstractSubprogramScopeDIE" in file DwarfDebug.cpp because the scope of the DISubprogram is null (I assume it should be the DICompileUnit). So I wou...

*From:* flang-dev <flang-dev-bounces at lists.flang-compiler.org> *On Behalf Of *Eric Schweitz (PGI) *Sent:* Thursday, November 01, 2018 1:02 PM *To:* flang-dev at lists.flang-compiler.org *Subject:* [Flang-dev] RFC: Adding debug information to LLVM to support Fortran In order to support debugging in the Flang project, work has been done to extend LLVM debug information for the Fortran

...;> >> It appears that the function is already inlined before >> strip-dead-debug-info starts its work. As a result the DICompileUnit is >> cleaned and its subprograms list has no reference to the DISubprogram for >> the inlined function, but as there is reference from the DILocalVariables >> to the DISubprogram it remains (IMHO). >> >> This caused to a segmentation fault while running llc on the optimized IR >> file at function "constructAbstractSubprogramScopeDIE" in file >> DwarfDebug.cpp because the scope of the DISubprogram is null (I assu...

Currently there is a series of patches undergoing review[0] that seek to enable the use of multiple IR/MIR values when describing a source variable's location. The current plan for the MIR is to add a new instruction, DBG_VALUE_LIST, that supports this functionality by having a variable number of operands. It may be better however to simply replace the existing DBG_VALUE behaviour entirely

...inline function with two local variables. It appears that the function is already inlined before strip-dead-debug-info starts its work. As a result the DICompileUnit is cleaned and its subprograms list has no reference to the DISubprogram for the inlined function, but as there is reference from the DILocalVariables to the DISubprogram it remains (IMHO). This caused to a segmentation fault while running llc on the optimized IR file at function "constructAbstractSubprogramScopeDIE" in file DwarfDebug.cpp because the scope of the DISubprogram is null (I assume it should be the DICompileUnit). So I wou...