Hi Brian,
Thanks for working on coroutines, the debugging experience, and in
particular thanks for the comprehensive write-up!,
On Thu, Feb 6, 2020 at 1:19 PM Brian Gesiak via llvm-dev
wrote:
> Specifically, I’m trying to improve lldb’s behavior when showing
> variables in the current stack frame, when that frame corresponds to a
> coroutine function.
[...]
Everything in the IR appears correct to my eyes, although I know next
to nothing about coroutines and might have missed something. The
simplest explanation of why the variable location goes missing can be
seen in the disassembly:
> ```
> 0x401885 <+373>: movq -0x8(%rbp), %rax
> 0x401889 <+377>: movl $0x0, 0x40(%rax)
> 0x401890 <+384>: X movl 0x28(%rax), %edx
> 0x401893 <+387>: X addl $0x1, %edx
> 0x401896 <+390>: X movl %edx, 0x28(%rax)
> 0x401899 <+393>: X movl 0x40(%rax), %edx
> 0x40189c <+396>: addl $0x1, %edx
> 0x40189f <+399>: movl %edx, 0x40(%rax)
> -> 0x4018a2 <+402>: movl 0x28(%rax), %esi
> ```
Where I've marked with 'X' before the mnemonic the instructions that
the variable location list covers. The location of "i" is correctly
given as edx from its load to its store, and ends when edx is
overwritten with the value of "j". In all the rest of the code, the
variables value is in memory, and the DWARF data doesn't record this.
Ideally debug info would track variables when they're stored to memory
-- however we don't automatically know whether any subsequent store to
memory will overwrite that variable, and so we don't track locations
into memory. PR40628 [0] is an example of what can go wrong, where we
described a variable as being in memory, but didn't know when that
location was overwritten.
If whatever's producing the coroutine IR has guarantees about where
and when variables are loaded/stored from/to memory, it should be
possible to put more information into the IR, so that the rest of LLVM
doesn't have to guess. For example, this portion of IR:
%15 = load i32, i32* %i.reload.addr62, align 4, !dbg !670
call void @llvm.dbg.value(metadata i32 %15, metadata !659, metadata
!DIExpression()), !dbg !661
%inc19 = add nsw i32 %15, 1, !dbg !670
call void @llvm.dbg.value(metadata i32 %inc19, metadata !659,
metadata !DIExpression()), !dbg !661
store i32 %inc19, i32* %i.reload.addr62, align 4, !dbg !670
Could have a call to llvm.dbg.addr(metadata i32 *%i.reload.addr66,
...) inserted after the store, indicating that the variable is located
in memory. This should work (TM) so long as that memory is never
overwritten with something that isn't the current value of "i" on
every path after the call to llvm.dbg.addr; and on every path after
the call to llvm.dbg.addr, when the variable is loaded form memory,
there's a call to llvm.dbg.value to indicate that the variable is
located somewhere other than memory now.
Providing that extra information should improve the location coverage
for your example, certainly when unoptimised. However, I believe (80%)
this method isn't safe against optimisation, because (for example)
dead stores can be deleted by LLVM passes without deleting the call to
llvm.dbg.addr, pointing the variable location at a stale value in
memory. Unfortunately I'm not aware of a facility or technique that
protects against this right now. (CC Reid who I think ran into this
last?).
Note that there's some support for tracking variables through stack
spills in post-isel debug data passes, however those loads and stores
operate in well defined ways, and general loads and stores might not.
[0] https://bugs.llvm.org/show_bug.cgi?id=40628
--
Thanks,
Jeremy
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
