search for: dw_op_plus

...;>>> BaseAddress, and add a constant offset corresponding to the logical >>>> variable. This should be the address of the logical variable. >>>> >>>> So, the DIExpression DIE would look something like: >>>> DW_OP_deref, DW_OP_constu, offset, DW_OP_plus >>>> >>>> But this does not work. I tried the variants with and without >>>> DW_OP_deref, but I always get the same wrong result when I test with >>>> LLDB. The offset is always added to the address of BaseAddress and not >>>> to its value...

...e GVE is added to, i.e. the value of >> BaseAddress, and add a constant offset corresponding to the logical >> variable. This should be the address of the logical variable. >> >> So, the DIExpression DIE would look something like: >> DW_OP_deref, DW_OP_constu, offset, DW_OP_plus >> >> But this does not work. I tried the variants with and without >> DW_OP_deref, but I always get the same wrong result when I test with >> LLDB. The offset is always added to the address of BaseAddress and not >> to its value. > > Can you share the final expr...

...seAddress, and add a constant offset corresponding to the logical >>>>> variable. This should be the address of the logical variable. >>>>> >>>>> So, the DIExpression DIE would look something like: >>>>> DW_OP_deref, DW_OP_constu, offset, DW_OP_plus >>>>> >>>>> But this does not work. I tried the variants with and without >>>>> DW_OP_deref, but I always get the same wrong result when I test with >>>>> LLDB. The offset is always added to the address of BaseAddress and not >>>&...

...e. the value of >>> BaseAddress, and add a constant offset corresponding to the logical >>> variable. This should be the address of the logical variable. >>> >>> So, the DIExpression DIE would look something like: >>> DW_OP_deref, DW_OP_constu, offset, DW_OP_plus >>> >>> But this does not work. I tried the variants with and without >>> DW_OP_deref, but I always get the same wrong result when I test with >>> LLDB. The offset is always added to the address of BaseAddress and not >>> to its value. >> >&gt...

...han the last needs salvaging, then you have to use DWARF stack operations to move it to the top of the stack. For example, if the elements are pushed in order so that the last element is on the top of the stack: %c = mul 3, %a %d = add 5, %b dbg.value(!DILocalVariable("x"), !DIExpression(DW_OP_plus), %c, %d) ; Salvage %d dbg.value(!DILocalVariable("x"), !DIExpression(DW_OP_plus_constu, 5, DW_OP_plus), %c, %b) ; Salvage %c needs to use DW_OP_swap dbg.value(!DILocalVariable("x"), !DIExpression(DW_OP_plus_constu, 5, DW_OP_swap, DW_OP_constu, 3, DW_OP_mul, DW_OP_plus), %a, %b)...

...the expression itself, allowing for binary operators with a constant operand to be salvaged: %c = add i32 %a, 4 llvm.dbg.value(metadata i32 %c, DILocalVariable("x"), DIExpression()) ; Salvage... llvm.dbg.value(metadata i32 %a, DILocalVariable("x"), DIExpression(DW_OP_constu, 4, DW_OP_plus)) This proposal is to allow multiple SSA value references within a debug intrinsic, allowing binary operators with non-constant operands to be salvaged. This is a long-awaited feature, with an open bugzilla[0] and support from members of the community[1][2]. To implement this change, each debug in...

...sically take the value of the global variable GVE is added to, i.e. the value of BaseAddress, and add a constant offset corresponding to the logical variable. This should be the address of the logical variable. So, the DIExpression DIE would look something like: DW_OP_deref, DW_OP_constu, offset, DW_OP_plus But this does not work. I tried the variants with and without DW_OP_deref, but I always get the same wrong result when I test with LLDB. The offset is always added to the address of BaseAddress and not to its value. The code for creating logical variables looks roughly like: llvm::SmallVecto...

...the global variable GVE is added to, i.e. the value of > BaseAddress, and add a constant offset corresponding to the logical > variable. This should be the address of the logical variable. > > So, the DIExpression DIE would look something like: > DW_OP_deref, DW_OP_constu, offset, DW_OP_plus > > But this does not work. I tried the variants with and without > DW_OP_deref, but I always get the same wrong result when I test with > LLDB. The offset is always added to the address of BaseAddress and not > to its value. Can you share the final expression as printed by llvm-dw...

>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

...g.value(DILocalVariable, DIExpression, ...) > > > > for example > > > > llvm.dbg.value_new(DILocalVariable("x"), DIExpression(DW_OP_LLVM_arg0), > %x) > > llvm.dbg.value_new(DILocalVariable("y"), DIExpression(DW_OP_LLVM_arg0, > DW_OP_LLVM_arg1, DW_OP_plus), > > %ptr, %ofs) > > llvm.dbg.value_new(DILocalVariable("z"), > DIExpression(DW_OP_implicit_pointer, DW_OP_LLVM_arg0, 32), > > DILocalVariable("base")) > > llvm.dbg.value_new(DILocalVariable("c"), DIExpres...

...neral form would be a more printf-like signature: llvm.dbg.value(DILocalVariable, DIExpression, ...) for example llvm.dbg.value_new(DILocalVariable("x"), DIExpression(DW_OP_LLVM_arg0), %x) llvm.dbg.value_new(DILocalVariable("y"), DIExpression(DW_OP_LLVM_arg0, DW_OP_LLVM_arg1, DW_OP_plus), %ptr, %ofs) llvm.dbg.value_new(DILocalVariable("z"), DIExpression(DW_OP_implicit_pointer, DW_OP_LLVM_arg0, 32), DILocalVariable("base")) llvm.dbg.value_new(DILocalVariable("c"), DIExpression(DW_OP_constu, 1)) The mandatory argum...

...ards, Alok On Wed, Nov 20, 2019 at 11:24 PM Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > Hi, > > For a new way of representing things, > > Adrian wrote: > > llvm.dbg.value_new(DILocalVariable("y"), DIExpression(DW_OP_LLVM_arg0, > DW_OP_LLVM_arg1, DW_OP_plus), > > %ptr, %ofs) > > I think this would be great -- there're definitely some constructs > created by the induction-variables pass and similar where one could > recover an implicit variable value, if you could for example subtract > one pointer from anoth...

...would be able to salvage variable locations that had gone out of liveness. Imagine for a moment that we described the "index" variable as a variadic variable location, possibly looking like this: DBG_INSTR_REF {3, 0}, {2, 0}, !17, !DIExpression(DW_OP_LLVM_arg, 0, DW_OP_LLVM_arg, 1, DW_OP_plus) Where the {3, 0} instruction number referred to the 'baz' argument, and {2, 0} the value of 'i' on entry to the loop body. The workflow for salvaging would look something like this, after LiveDebugValues has finished doing dataflow things: 1) Examine instruction reference {3, 0}...

...t;>>> Hi, >>>>> >>>>> For a new way of representing things, >>>>> >>>>> Adrian wrote: >>>>> > llvm.dbg.value_new(DILocalVariable("y"), >>>>> DIExpression(DW_OP_LLVM_arg0, DW_OP_LLVM_arg1, DW_OP_plus), >>>>> > %ptr, %ofs) >>>>> >>>>> I think this would be great -- there're definitely some constructs >>>>> created by the induction-variables pass and similar where one could >>>>> recover an implic...

...eremy.morse.llvm at gmail.com> wrote: >> >>> Hi, >>> >>> For a new way of representing things, >>> >>> Adrian wrote: >>> > llvm.dbg.value_new(DILocalVariable("y"), DIExpression(DW_OP_LLVM_arg0, >>> DW_OP_LLVM_arg1, DW_OP_plus), >>> > %ptr, %ofs) >>> >>> I think this would be great -- there're definitely some constructs >>> created by the induction-variables pass and similar where one could >>> recover an implicit variable value, if you could for exam...

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

Apologies for the slow response here Jeremy. Your reply has been incredibly helpful so far, I just need to try adding 'llvm.dbg.addr' myself to confirm that works. Thank you! - Brian Gesiak On Thu, Feb 6, 2020 at 11:04 AM Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > Hi Brian, > > Thanks for working on coroutines, the debugging experience, and in > particular

Hello, Thanks for prompt reply. Motivation, In case of debugging of bi-endian dwarf and value known at runtime some of the raw values needs to be byte swapped to change the endianity. We have a llvm based compiler which generates such dwarf, TAG_variable marked as big endian and debugging on little endian host using lldb. The listed operator on dwarf issues does that, one operator instead of

Hi Djordje, [Late reply as I was away, alas], For the example in https://reviews.llvm.org/D85012 , I'm not sure that just using an entry value is correct. The reason why the dbg.values for arguments are set to undef is not because the value can't be described, it's because deadargelim changes all the call sites to pass in 'undef', which I believe makes the value unrecoverable

...presenting things, >>>>>>>>>> >>>>>>>>>> Adrian wrote: >>>>>>>>>> > llvm.dbg.value_new(DILocalVariable("y"), >>>>>>>>>> DIExpression(DW_OP_LLVM_arg0, DW_OP_LLVM_arg1, DW_OP_plus), >>>>>>>>>> > %ptr, %ofs) >>>>>>>>>> >>>>>>>>>> I think this would be great -- there're definitely some constructs >>>>>>>>>> created by the induction-v...