search for: dw_op_deref

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

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

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

...xpression called 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 r...

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

...ld 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. Can you share the fina...

...an elide DW_OP_stack_value for DBG_VALUEs >> with physical register operands. They just use DW_OP_regN, which is >> implicitly a value location. >> 6. Teach all passes that spill virtual registers used by DBG_VALUE to >> remove DW_OP_stack_value from the DIExpression, or add DW_OP_deref as >> appropriate. >> >> This should be equivalent to DW_OP_LLVM_memory, and more inline with >> DWARF location expression semantics, but it has a large migration cost. >> >> --- >> >> I think part of the reason I wanted to move in the DW_OP_LLVM_memo...

...BG_VALUEs >>>> with physical register operands. They just use DW_OP_regN, which is >>>> implicitly a value location. >>>> 6. Teach all passes that spill virtual registers used by DBG_VALUE to >>>> remove DW_OP_stack_value from the DIExpression, or add DW_OP_deref as >>>> appropriate. >>>> >>>> This should be equivalent to DW_OP_LLVM_memory, and more inline with >>>> DWARF location expression semantics, but it has a large migration cost. >>>> >>>> --- >>>> >>>> I...

...siginfo* %siginfo, metadata !6793, metadata !DIExpression()) #6, !dbg !6967 call void @llvm.dbg.value(metadata %struct.siginfo* %siginfo, metadata !6937, metadata !DIExpression()) #6, !dbg !6942 call void @llvm.dbg.value(metadata %struct.siginfo* %siginfo, metadata !6556, metadata !DIExpression(DW_OP_deref)), !dbg !6931 call void @llvm.dbg.value(metadata %struct.siginfo* %siginfo, metadata !6556, metadata !DIExpression(DW_OP_deref)), !dbg !6931 call void @llvm.dbg.value(metadata %struct.siginfo* %siginfo, metadata !6556, metadata !DIExpression(DW_OP_deref)), !dbg !6931 E.g. here the second and t...

...at references the dummy argument, N. call void @llvm.dbg.declare(metadata i64* %N, metadata !113, metadata !DIExpression()) … !110 = !DIFortranArrayType(baseType: !7, elements: !111) !111 = !{ !112 } !112 = !DIFortranSubrange(lowerBound: 1, upperBound: !113, upperBoundExpression: !DIExpression(DW_OP_deref)*)* !113 = !DILocalVariable(scope: !2, name: “zb1”, file: !3, type: !4, flags: DIFlagArtificial) It turned out that gdb didn’t properly interpret location lists or variable references in the DW_AT_lower_bound and DW_AT_upper_bound attribute forms, so the compiler must generate either a constant...

...stack slot address of a variable to an existing expression. Now the problem here is that the former is a 'Memory location description' while the latter could very well be a 'Implicit location description' (e.g. the sign extension from lib/Transforms/Utils/Local.cpp) in which case a DW_OP_deref of some sort would be needed in between. To me it seems that there is no clear way of knowing what to do when concatenating because there is no clear way of knowing the kind of the existing expression (is it Memory, Register or Implicit). Without having thought too much about it it would seem t...

...ns as necessary. In particular, we can elide DW_OP_stack_value for DBG_VALUEs with physical register operands. They just use DW_OP_regN, which is implicitly a value location. 6. Teach all passes that spill virtual registers used by DBG_VALUE to remove DW_OP_stack_value from the DIExpression, or add DW_OP_deref as appropriate. This should be equivalent to DW_OP_LLVM_memory, and more inline with DWARF location expression semantics, but it has a large migration cost. --- I think part of the reason I wanted to move in the DW_OP_LLVM_memory direction is that I originally wanted to add a memory offset opera...

> From: aprantl at apple.com <aprantl at apple.com> > Since it sounds like the problem is only with implicit descriptions, would a rule > such as "if the expression has a DW_OP_stack_value, add an extra > DW_OP_deref" work for the PrologueEpilgueInserter or do we need > something more principled? Right, that could very well be sufficient for this particular case so I will experiment with that. In general though and for the future it seems that it would be of benefit to have additional metadata in the e...

> I can see how that could potentially be useful. I'm not sure how often we could practically make use of a situation like this, but I understand your motivation. Indeed, I don't expect us to cancel out DWARF expressions like that very often. Although that edge case is likely to be very rare, the _direct operator itself will appear very frequently, as it would be used for every

...ct). > 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 this question — is there a difference between > > dbg.value(my_alloca, var, !DIExpression(DW_OP_deref, DW_OP_LLVM_direct)) > > and > > dbg.value(my_alloca, var, !DIExpression(DW_OP_deref)) ? So with that in mind, we wouldn't need to produce these, as in both cases the intent would be that the value of "var" is at the address given by "my_alloca". When we produce...

...k_value denotes that we reconstructed the value of the variable, but it doesn't exist in the program ("The DW_OP_stack_value operation specifies that the object does not exist in memory but its value is nonetheless known"), for example, a constant value. I think we want something like DW_OP_deref instead, at least for r-values. For l-values (=variables a debugger could write to) we would need to have a discriminator that declares the DBG_VALUE as a memory location (cf. DWARF5 chapter 2.6). This is a tricky one. Right now, DIExpressions sort-of mimic DWARF, but with differences that aren...

...on that references the dummy argument, N. call void @llvm.dbg.declare(metadata i64* %N, metadata !113, metadata !DIExpression()) … !110 = !DIFortranArrayType(baseType: !7, elements: !111) !111 = !{ !112 } !112 = !DIFortranSubrange(lowerBound: 1, upperBound: !113, upperBoundExpression: !DIExpression(DW_OP_deref)) It would be better (and much more robust in presence of optimizations) if the DIExpression were part of a @llvm.dbg.declare / value intrinsic tying the DILocalVariable to an LLVM SSA value. !113 = !DILocalVariable(scope: !2, name: “zb1”, file: !3, type: !4, flags: DIFlagArtificial) It turned out...

> 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

On Tue, Sep 18, 2018 at 1:56 AM Adrian Prantl <aprantl at apple.com> wrote: > > > > > On Sep 17, 2018, at 6:59 AM, Alexander Potapenko via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > (I think I've asked a similar question off-list a couple of times, but > > never got an answer) > > > > Hi folks, > > > > For [K]MSAN

...Direct 0, (), -> DW_OP_breg7 RSP+0 Memory l-value Indirect $noreg, (deref), -> DW_OP_breg7 RSP+0 Memory l-value Indirect 0, (deref), -> DW_OP_breg7 RSP+0, DW_OP_deref Memory l-value Indirect The point of using DW_OP_LLVM_direct is that it supplants the current directness flag, without the redundancy or unintuitive behaviour that the flag does. I believe the only reason that the indirectness flag is necessary right now is to allow register locations t...