search for: dbg_valu

Hi, I have a case that is causing me grief in the form of an assert. The prolog Epilog inserter tries to remove Frame Index references. I have a DBG_VALUE instruction that looks like this (alongwith the Frame Index). This is for the Hexagon backend. ************************** fi#2: size=4, align=4, at location [SP-84] DBG_VALUE <fi#2>, 0, !"fooBar"; line no:299 ************************** Clearly, the FI in question is at an offset o...

On Mar 7, 2012, at 5:19 PM, Pranav Bhandarkar <pranavb at codeaurora.org> wrote: > Hi, > > I have a case that is causing me grief in the form of an assert. The prolog > Epilog inserter tries to remove Frame Index references. I have a DBG_VALUE > instruction that looks like this (alongwith the Frame Index). This is for > the Hexagon backend. > ************************** > fi#2: size=4, align=4, at location [SP-84] > DBG_VALUE <fi#2>, 0, !"fooBar"; line no:299 > ************************** > > Clear...

Here is a proposal for improving DbgValueHistoryCalculator and the overall quality of debug locations. Focus: This is about lowering the DBG_VALUE machine instructions to DWARF location lists. Non-focus: This is not about (typical -O0) variables that permanently reside at a frame index and are described with dbg.declare intrinsics in the IR. These variables are stored in the MMI side-table and processed separately. The semantics of DBG_VA...

I have a question regarding the DBG_VALUE instruction. IIUC the DBG_VALUE appears in two different forms: 1. DBG_VALUE( %Reg, %Reg, metadata) 2. DBG_VALUE(%Reg, offset, metadata) In the first version, the second operand is always a %noreg in the form of: DBG_VALUE(%Reg, %noreg, metadata). Is it possible to have a different version of...

Hi debuginfo cabal, tl;dr: I'd like to know what people think about an alternative to DBG_VALUE instructions describing variable locations in registers, virtual or real. Before instruction selection in LLVM-IR we identify the _values_ of variables [0] by the instruction that computes the value; I believe we should be able to do the same post-isel, and it would avoid having to analyse registe...

...2011, at 10:26 AM, Richard Osborne wrote: >> I'm investigating a bug associated with debug information that manifests >> itself in the XCore backend (PR11105). I'd like to understand what the >> expected behavior of eliminateFrameIndex() is when it is called on a >> dbg_value machine instruction. > That is up to the target. > > The TII::emitFrameIndexDebugValue() hook is called to insert DBG_VALUE instructions referring to values on the stack. Thanks for pointing this out. Looking at the code in constructVariableDIE it seems to use the number of operands to d...

I'm investigating a bug associated with debug information that manifests itself in the XCore backend (PR11105). I'd like to understand what the expected behavior of eliminateFrameIndex() is when it is called on a dbg_value machine instruction. Currently the XCore target replaces the frame index with the frame register and sets the next operand to the byte offset from the frame register. A quick glance at some of the other targets suggests this is the right thing to do (for example ARMBaseRegisterInfo::eliminate...

On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: > I'm investigating a bug associated with debug information that manifests > itself in the XCore backend (PR11105). I'd like to understand what the > expected behavior of eliminateFrameIndex() is when it is called on a > dbg_value machine instruction. That is up to the target. The TII::emitFrameIndexDebugValue() hook is called to insert DBG_VALUE instructions referring to values on the stack. The target's eliminateFrameIndex() should be able to handle any DBG_VALUE instructions created by this hook. If you don't...

Hi, The insertion of DBG_VALUE instructions for spills does not seem to be handling insert locations inside bundles well. If the spill instruction is part of a bundle, the new DBG_VALUE is inserted after it, but does not have the bundling flags set. This essentially means that if we start with a set of bundled instructions: MI...

...is issue. Please note that since the problem results in broken bundles, it can result in invalid schedules for any VLIW back-ends using bundling to group instructions. Best regards Saurabh Verma From: Verma, Saurabh Sent: Tuesday, December 19, 2017 4:14 PM To: llvm-dev at lists.llvm.org Subject: DBG_VALUE insertion for spills breaks bundles Hi, The insertion of DBG_VALUE instructions for spills does not seem to be handling insert locations inside bundles well. If the spill instruction is part of a bundle, the new DBG_VALUE is inserted after it, but does not have the bundling flags set. This essen...

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 instead, and so I'm looking for any comments on this change before pushing ahead with it. There are a few differences between th...

...ins a value defined by the "somedef" instruction, b) The DBG_INSTR_REF needs a location for the value somedef defines. c) That value from "somedef" is copied to rbx, The new LiveDebugValues implementation doesn't have DBG_INSTR_REF yet, so I've written it to work with DBG_VALUEs too, to prove that it works just as well as the current implementation. It deals with code sequences such as: $rax = somedef DBG_VALUE $rax $rbx = COPY killed $rax ; Variable location is $rax, then moves to $rbx In which the same tracking has to occur, but the DBG_VALUE "re...

Hi, I work with an out-of-tree backend for a VLIW architecture and we use bundling extensively. We have opted to put DBG_VALUES inside bundles to keep them together with their originating instructions. However, as no (in-tree) backends do this to our knowledge, we have recently started to question if that's a wise approach. Several patches are needed to make bundled DBG_VALUEs work and since others don't do it, we...

...ted solution and analysis in DbgValueHistoryCalculator... On Tue, Jun 23, 2015 at 4:41 PM, Adrian Prantl <aprantl at apple.com> wrote: > Here is a proposal for improving DbgValueHistoryCalculator and the > overall quality of debug locations. > > Focus: This is about lowering the DBG_VALUE machine instructions to > DWARF location lists. > > Non-focus: This is not about (typical -O0) variables that permanently > reside at a frame index and are described with dbg.declare intrinsics > in the IR. These variables are stored in the MMI side-table and > processed separate...

Hi, (Resent with proper subject line) I recently found myself in trouble because the crash I had disappeared with -g, so I could not debug the program. This happened because the optimizer did not remember to consider DBG_VALUEs instruction so it changed its behavior, and the bug went hiding. I then started discussing this onhttps://reviews.llvm.org/D45878, and since this is something that should be handled by all different machine passes, the immediate question is now what utility functions should be made available fo...

...m.org> wrote: > > Hi, (Resent with proper subject line) > > I recently found myself in trouble because the crash I had disappeared > with -g, so I could not debug the program. This happened because the > optimizer did not remember to consider DBG_VALUEs instruction so it > changed its behavior, and the bug went hiding. [Here are some (very high-level) thoughts.] As you suspect, that's clearly a bug. LLVM's ideal behavior is that the presence of debug informations shall not affect the contents of the .text section. As you also notice...

Hi Xiang, On Wed, Nov 11, 2020 at 1:59 AM Zhang, Xiang1 <xiang1.zhang at intel.com> wrote: > Jeremy wrote: > > ... The value %0 is live up to and including the ADD64ri but not past it, meaning LLVM today will drop the DBG_VALUE ... > > Just a little puzzle about the " drop the DBG_VALUE ", maybe I didn't get your key point, > So I write a phi case, it like > ___________________________________________________ > vaarg.end:...

+llvmdev -llvm-commits Hi! I've got the following questions about DBG_VALUE instruction: 1) When I dump this instruction I see the line of the form: DBG_VALUE %EDI, 0, !"a"; line no:47 for two completely different cases: * when value of "a" is actually stored in a register %edi (this should be encoded as "DW_OP_reg5" in DWARF). * when...

..., 2016, at 11:00 AM, Francois Pichet <pichet2000 at gmail.com> wrote: > > Here is a specific case that make the debugging experiences degraded on my target: > This is a loop simplified CFG: > > BB#0: > %R5<def> = OR_rr %R0, %R49 // this is %R5 only def. > DBG_VALUE %R5, %noreg, !"argc", <!18>; line no:4 > Successors according to CFG: BB#1 > > BB#1: > Live Ins: %R5 > Predecessors according to CFG: BB#0 BB#3 > ... > Successors according to CFG: BB#2 BB#4 > > BB#2: > Live Ins: %R5 > P...

..._value (I believe). As discussed, one of the key distinctions that DW_OP_LLVM_direct is used for is distinguishing between memory and register locations; this is exactly the same as the difference between dbg.addr(%a, "a", ()) and dbg.value(%a, "a", ()). The former would become DBG_VALUE %a, "a", () and the latter would become DBG_VALUE %a, "a", (DW_OP_LLVM_direct). > Do you have an example of a a dbg.value that isn't a DW_OP_stack_value where it makes sense to distinguish between a memory and a register location? > > Perhaps another way to phrase...