jasonmolenda wrote:
Interesting PR, thanks for looking at adding these annotations. I think
exposing these dwarf location expressions in a more user-visible way is going
to put a lot of pressure on making them more meaningful to users, as opposed to
debugging prints for debugger/compiler developers. Another example of an
unfortunate behavior on AArch64 where x0 is the 64-bit register name, w0 is the
32-bit register name, but the DWARF register number doesn't specify which it is
(it depends on the type of the value to read 32- or 64-bits), so the expression
parser always prints the "w" register by default which might be a little
confusing.
One thing which is obviously correct, but was unintuitive at first for me, was
that the DWARF location is only known after the instruction initializing it,
e.g.
```
0x5555555551f7 <+7>: xorl %ebx, %ebx
0x5555555551f9 <+9>: nopl (%rax) ; my_special_variable = DW_OP_reg3 RBX
```
for `uint32_t my_special_variable = 0`. The comment on +9 is really reflecting
what has been done when +7 has executed. It's CORRECT, but at first blush it's
not what I'd have expected. I think changing this would be more confusing when
people are examining edge cases than otherwise. Also in the sample codegen, we
see `my_special_variable` cease to exist for a little when that register is
reused as `new_variable` == `my_special_variable+1` and then that same incr
value becomes `my_special_variable` when we loop and we avoid incrementing it
again. Oh well, that's the fun of reading assembly code, no way to make that
easier.
https://github.com/llvm/llvm-project/pull/147460
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
