[Lldb-commits] [lldb] [llvm] Annotate disassembly with register‐resident variable locations (PR #147460)
Jason Molenda via lldb-commits
lldb-commits at lists.llvm.org
Wed Jul 16 17:56:06 PDT 2025
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
More information about the lldb-commits
mailing list