search for: dw_op_constu

...ret i32 %mul, !dbg !31 ; Combine redundant instructions, "a" is salvaged... %call = call i32 @_Z3bazv(), !dbg !25 %call1 = call i32 @_Z3barv(), !dbg !26 %add = add nsw i32 %call, %call1, !dbg !27 call void @llvm.dbg.value(metadata i32 %add, metadata !24, metadata !DIExpression(DW_OP_constu, 4, DW_OP_minus, DW_OP_stack_value)), !dbg !28 %sub = shl i32 %add, 1, !dbg !29 %mul = add i32 %sub, -8, !dbg !29 ret i32 %mul, !dbg !30 ; bar() is found to always return 4 %call = call i32 @_Z3bazv(), !dbg !14 %add = add nsw i32 %call, 4, !dbg !15 call void @llvm.dbg.value(metadata i3...

...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 >>&...

...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. > > Can you...

...gt;>>>> 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 a...

...le 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 valu...

>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 distinguish between > >dbg.value(!DILocalVariable(x), DIExpression(DW_OP_constu, 42)) ; a constant >dbg.value(i32 42, !DILocalVar...

.... Supporting the no-op DIExpression reduction is unlikely to have a huge impact in itself, but having a "stack_value that could be an l-value" nicely rounds out the LLVM representation for debug values. >If we had DW_OP_LLVM_direct: what would be the semantics of > >DIExpression(DW_OP_constu, 4, DW_OP_minus, DW_OP_LLVM_direct) > >versus > >DIExpression(DW_OP_constu, 4, DW_OP_minus) ? Once we have the _direct operator, which will be used for all register locations and some implicit locations, we can safely say that any expression that isn't _direct, implicit, or empty w...

...ariable("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) Or, written out as the stack state: [%a, %b] ; Initial state [%a, %b + 5] ; DW_OP_plus_constu, 5 [%b + 5, %a] ; DW_OP_swap [%b + 5, %a, 3] ; DW_OP_constu, 3 [%b + 5, %a * 3] ; DW_OP_mul [(%b + 5) + (%a * 3)] ; DW_O...

...led DIE that should basically 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:...

...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. Can you share the final expression a...

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 Adrian & Stephen, One thought here: But — not all memory locations are l-values. If we have a DWARF location list for variable "x" which points to a memory address for the first n instructions and the switches to a constant for the remainder of the scope, the memory address is not guaranteed to be an l-value, because writing the the memory address cannot affect the later part of

...y explain what it is? https://llvm.org/docs/LangRef.html In one ll file converted from bitcode, I mostly see something like this. !8273 = !DIGlobalVariableExpression(var: !8274, expr: !DIExpression()) Only one looks like this. !8945 = !DIGlobalVariableExpression(var: !8946, expr: !DIExpression(DW_OP_constu, 44, DW_OP_stack_value)) Why DIExpression is mostly empty? -- Regards, Peng

...presented within 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...

...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 arguments would be the variable and the expression, and an arbitrary number of SSA values and potentially other variables. As far as DW_OP_LLVM_implicit_pointer in particular is concerned, we could also treat the peculiarities of DW_OP_implicit_pointer as a DWARF implementatio...

> Can you elaborate what "direct" means? I'm having trouble understanding what the opposite (a non-exact value) would be. Apologies, "exact" was a misleading/incorrect term. By direct, I mean that the expression computes the value of the variable, as opposed to its memory address, or the value that it points to. Within LLVM, where we don't have DW_OP_reg/DW_OP_breg

...+ 5; int c = b - 5; If both b and c are optimized out and salvaged, then we end up with the following dbg.values: @llvm.dbg.value(i32 %a, !"b", !DIExpression(DW_OP_plus_uconst, 5, DW_OP_LLVM_direct)) @llvm.dbg.value(i32 %a, !"c", !DIExpression(DW_OP_plus_uconst, 5, DW_OP_constu, 5, DW_OP_minus, DW_OP_LLVM_direct)) ; DIExpressions optimized... @llvm.dbg.value(i32 %a, !"b", !DIExpression(DW_OP_plus_uconst, 5, DW_OP_LLVM_direct)) @llvm.dbg.value(i32 %a, !"c", !DIExpression(DW_OP_LLVM_direct)) In this admittedly strange case, we start with b a...

...gt; !0 = !DIGlobalVariableExpression(var: !DIGlobalVariable(...), expr: !DIExpression()) > > implicitly pushes the first arg, but this form > > !0 = distinct !DICompileUnit(..., globals: !{!1}, ...) > !1 = !DIGlobalVariableExpression(var: !DIGlobalVariable(...), expr: !DIExpression(DW_OP_constu, 42, DW_OP_stack_value)) Ah. > doesn't. So considering that, we may have to move the bit into the expression itself (e.g., by adding a version number to the bitcode for DIExpression). Hrm, fair enough. Thanks for the context! - Dave > > -- adrian > > > > >> >...

On Wed, Jul 8, 2020 at 9:29 AM Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > > On Jul 8, 2020, at 5:21 AM, Tozer, Stephen <stephen.tozer at sony.com> wrote: > > > >> To summarize my understanding: Neither of these operators is strictly necessary, since the same effect can be achieved by implicitly pushing all operands of a

On Tue, May 10, 2016 at 3:03 PM, Adrian Prantl <aprantl at apple.com> wrote: > > On May 9, 2016, at 4:42 PM, Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Mon, May 9, 2016 at 4:26 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Mon, May 9, 2016 at 3:38 PM, Peter Collingbourne <peter