[cfe-dev] RFC: Remove uninteresting debug locations at -O0

[Robinson, Paul via cfe-dev]

> -----Original Message-----
> From: Adrian Prantl <aprantl at apple.com>
> Sent: Wednesday, April 29, 2020 12:37 PM
> To: Reid Kleckner <rnk at google.com>
> Cc: Clang Dev <cfe-dev at lists.llvm.org>; Shafik Yaghmour
> <syaghmour at apple.com>; Vedant Kumar <vsk at apple.com>; Davidino Italiano
> <ditaliano at apple.com>; David Blaikie <dblaikie at gmail.com>; Robinson, Paul
> <paul.robinson at sony.com>; Jeremy Morse <jeremy.morse.llvm at gmail.com>;
> Pavel Labath <labath at google.com>
> Subject: Re: RFC: Remove uninteresting debug locations at -O0
> 
> Thanks to all of you for sharing your perspective! You all brought up
> important aspects that I hadn't considered. The argument that really
> clicked for me was Pavel's that you might want to change the value before
> the load happens.

That's definitely one thing a debugger user would like to do.
Another is something like a "do-over" which we've tried to support in our
debugger: you've stepped to line 27, had your "aha" moment, diddled some
values, now you drag your cursor back to line 24 and click "step".  This
can only work if all the instructions contributing to line 24 are actually
attributed to line 24.

Let me point out another aspect of what happens when you've done the load:
The value now exists in two places.  DWARF is able to describe this with
location lists (entry ranges are explicitly permitted to overlap) although
LLVM doesn't have a way to track or report that.  If we did, then Pavel's
scenario would work fine with Adrian's idea, because the debugger would be
able to update *both* places that had the value (assuming the debugger was
alert to the possibility of a value in multiple places).
--paulr

> 
> One of my worries here is that what I called "less interesting" locations
> might delete more interesting ones when instructions and their locations
> are merged. But if we indeed consider the stack slot loads to be
> interesting then that is really the best we can do. After all, storing
> more than source location per instruction would be a UI design nightmare
> for a debugger.
> 
> 
> Reid, I would like to learn more about what you mean by statement
> tracking. I'm thinking of a statements as the expressions separated by
> semicolons, but since my whole example was a single statement I'm assuming
> you have something more fine-grained in mind. Perhaps you can post an
> example to illustrate what you have in mind?
> 
> 
> thanks!
> -- adrian