[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