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

[Robinson, Paul via llvm-dev]

> -----Original Message-----
> From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Pavel Labath
> via cfe-dev
> Sent: Wednesday, April 29, 2020 7:27 AM
> To: Adrian Prantl <aprantl at apple.com>
> Cc: Davidino Italiano <ditaliano at apple.com>; Clang Dev <cfe-
> dev at lists.llvm.org>
> Subject: Re: [cfe-dev] RFC: Remove uninteresting debug locations at -O0
> 
> On Tue, 28 Apr 2020 at 22:58, Adrian Prantl via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > or will inherit whatever debug location the instruction before it has
> 
> This part looks worrying to me. Would that mean, that if in your
> example, I set a breakpoint on line 7, the program would stop directly
> at the callq instruction? That seems like it would break the following
> flow:
> b 7
> run
> # program stops at line 7
> p foo
> # hmm... that value isn't right, lemme see what happens if I change it
> p foo = other_foo
> continue
> 
> In non-optimized builds I would expect to be able to make these kinds
> of modifications to the program and things should generally "work". In
> that sense, maybe these loads are not "uninteresting" as they are what
> makes these modifications take effect.

There are a couple of things going on here, which are about perceptions
and the user experience.

First is the source-syntactic difference between method and function calls:
    foo->getFoo();
    getFoo(foo);
These turn into the same instruction sequence (load foo and call getFoo).
In the second case, I think it's pretty clear we'd want to stop before
we start loading the arguments.  In the first case the syntax tricks us
into thinking the load isn't part of the calling sequence; but it still is.

Second is the broader and more hand-wavy aspect of "what is a statement"
and "how many points within a subexpression are we going to distinguish"
which DWARF itself is not particularly helpful about, and does its own
hand-wavy thing with the poorly named "quality of implementation" rubric.

I don't think arbitrarily deciding "loads are not interesting" is a good
heuristic.  Personally I think the user needs better training. 😊
--paulr

> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://urldefense.com/v3/__https://lists.llvm.org/cgi-
> bin/mailman/listinfo/cfe-dev__;!!JmoZiZGBv3RvKRSx!um57gcS-
> kBD9J9PKc1xkAQCq81IpYpQqL0j-KjdhCW43A3Y2-Hh6i9ZwDQ47l39wLQ$