Designs for better debug info in GCC

[Alexandre Oliva]

On Nov 26, 2007, Michael Matz <matz@suse.de> wrote:

> Hi,
> On Fri, 23 Nov 2007, Alexandre Oliva wrote:

>> Yep.  Nowhere does that bug report request parameters to be forced live.  

> Not in that bug report perhaps, but we got requests for exactly this, i.e. 
> to be able to introspect all parameters of all functions, be they inlined 
> or not, at all time.  I think that's a reasonable request even (which in 
> some situations comes at a cost).

Fair enough.  And we agree this is not about debug info, it's about
limiting optimizations, so this is indeed a different problem from the
one I was asked to address.

>> 2. function is inlined, the argument is unused and thus optimized
>> away, but the function does some other useful computation
>> 
>> At the inlined entry point, we have a note that binds the argument to
>> its expected value.  As we transform the program and optimize away the
>> argument, we retain and update the note,

> As far as possible.  If it's not possible you loose (with our 
> requirements).

If the argument is completely removed, yes, you won't be able to get
to it by merely improving debug information.  You actually have to
change the generated code.

>> If the value of a variable is completely optimized away at a point in 
>> the porogram, the correct representation for its location at that point 
>> is an empty set.

> I think this is academic.  If a value is dead, but happens to lie in a 
> place which isn't yet overwritten with something else, it is harmless to 
> reveal this value.  It's the "last" value the variable had.  If OTOH the 
> place _is_ already overwritten then it's important that we _don't_ say the 
> dead variable lies therein.

Exactly.  Full agreement.  I wasn't talking about the *location* of
the variable, or the variable itself.  I was talking about the value.
And I wrote "completely optimized away", not "dead".  Liveness has
very little to do with this issue.

The only catch is that, once a variable should be *expected* to hold a
different value, if debug information still claims the variable still
holds the old value it shouldn't hold any more, just because the value
happens to be around and the assignment of the new value could be
optimized away, then I'd say debug information is incorrect.

> So, for me correctness is defined a bit different than for you:
> 1) if location L contains value X, then debug info should say so (as much 
>    as possible, i.e. here the quality of the info comes into play)
> 2) if location L does not contain value X, debug info should not say that 
>    it does.  This is the correctness part.

Your definition is exactly what I've been trying to communicate.  It
looks like we're in complete agreement as to the goals and the two
different metrics (1 being completeness, 2 being correctness).  So
either there's some other underlying difference or you'll soon realize
that the simple SSA name<->variable mapping is insufficient to get you
correctness.

> Where we differ in opinion (I think) is, when location L doesn't contain 
> value X anymore.  For you it's when X becomes dead.  For me it's when X is 
> dead and when location L is overwritten (with something different than X).  

For me, it's when X is overwritten.  That's the point at which the
user is entitled to expect the variable to no longer hold its previous
value (assuming they're different).

Consider this program:

int foo(int x) {
  int i;

  i = x;
  p1();
  i++;
  p2(i);
  i++;
  p3();
}

int main() {
  foo(1);
}

If you set a breakpoint in p1(), go up one frame and print i, you
should ideally get 1 (although "unavailable" is always correct, even
if undesirable).  If you set a breakpoint in p2(int), you should get
2, but "unavailable" is quite likely in the presence of optimization,
depending on the calling conventions.  If you set a breakpoint in
p3(), you should get 3, but "unavailable" is quite likely, given that
the value is not even computed, and it's based on a value that is dead
and thus may have been overwritten.

Getting any other values at any of these points would be a bug in the
compiler.

Does this sound sound to you?

Did you somehow get the impression that the SSA<->names mapping can
get you correct results?

>> Accuracy comes first.  If we ever emit debug information saying 'this
>> variable is here' for a point in the program in which it's in fact
>> elsewhere

> I agree here ...

>> or unavailable, that's a bug to be fixed.

> ... and disagree here.  If a value is dead it's not necessarily 
> unavailable in my world.

I never said "dead", you did.  I said "unavailable", and by that I
don't mean "dead", I really mean "unavailable".  The value I'm talking
about is not "whatever was last assigned to something that resembles
the variable after numerous optimizations" but rather "a value the
user might expect the variable to hold at that point in the program",
given some user tolerance to reordering and other optimizations.

One reason I use separate functions for the breakpoint locations is
precisely because at those points users are entitled to expect the
state of the program to be stable, i.e., there isn't a lot of
reordering or other surprises that a compiler can introduce across
function calls that are by themselves in a statement.

Another reason is that I still don't have a good answer for breakpoint
locations at other points in the program that are less stable across
optimizations, and I can't quite describe what I think users are
entitled to expect at such other points.  But the infrastructure
needed to bring great improvements even in this regard is being set in
place by getting them correct at stable points such as function calls.

That said, I'm putting some thought into getting better debug
information in these less stable points, but making it completely
unsurprising in spite of optimizations isn't the task I was assigned.
Making it correct and far more complete is.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}