search for: dw_op_reg5

...sembly and location list for 'bar': 0x0000000000400483 <+3>: mov %esi,%ebx 0x0000000000400485 <+5>: mov %edi,%ebp => 0x0000000000400487 <+7>: callq 0x4004d0 <ext> DW_AT_location (0x00000000: [0x0000000000400480, 0x0000000000400487): DW_OP_reg5 RDI [0x0000000000400487, 0x00000000004004a3): DW_OP_reg6 RBP) Stepping through the function, we stop on the call to 'ext', and can set the value of 'bar', but because there are two locations (and LiveDebugValues picked the long term register $ebp rather than $edi), you can set &q...

...he following questions about DBG_VALUE instruction: 1) When I dump this instruction I see the line of the form: DBG_VALUE %EDI, 0, !"a"; line no:47 for two completely different cases: * when value of "a" is actually stored in a register %edi (this should be encoded as "DW_OP_reg5" in DWARF). * when value of "a" is stored in memory at address stored in %edi ("DW_OP_breg5, 0" in DWARF). Currently LLVM handles this in favor of first case, and produces wrong debug info for the second case. Can these cases actually be distinguished, and if yes, where...

Hi debuginfo-cabal, tl;dr: Let's please consider using a new implementation of LiveDebugValues that produces richer information, might be slightly faster, but mostly will support the instruction referencing and value tracking paradigm from my RFC [0] rather than the location tracking that LiveDebugValues does today. In that RFC, the main motivator is to treat variable locations a bit more