Re: Designs for better debug info in GCC

[Ian Lance Taylor <iant at google dot com>]

Alexandre Oliva <aoliva@redhat.com> writes:

> 	A plan to fix local variable debug information in GCC
> 
> 		by Alexandre Oliva <aoliva@redhat.com>
> 
> 			   2007-12-18 draft

Thank you for writing this.  It makes an enormous difference.


> == Goals

I note that you don't say anything about the other big problem with
debugging optimized code, which is that the debugger jumps around all
over the place.  That is fine, of course.


> Once this is established, a possible representation becomes almost
> obvious: statements (in trees) or instructions (in rtl) that assert,
> to the variable tracker, that a user variable or member is represented
> by a given expression:
> 
>   # DEBUG var expr
> 
> By var, we mean a tree expression that denotes a user variable, for
> now.  We envision trivially extending it to support components of
> variables in the future.

While you say that this is almost obvious, it still isn't obvious at
all to me.  You consider trees and RTL together, but I don't see why
that is appropriate.

My biggest concern at the tree level is the significantly increased
memory usage and the introduction of a sort of a weak pointer to
values.  Since DEBUG statements shouldn't interfere with
optimizations, we need to explicitly ignore them in things like
has_single_use.  But since our data structures need to be coherent, we
can not ignore them when we actually eliminate SSA names.  That seems
sort of complicated.

In SSA form it seems very natural to provide a set of associations
with user variables for each GIMPLE variable.  Since the GIMPLE
variables never change, these associations never change.  We have to
get them right when we create a new GIMPLE variable and when we
eliminate a GIMPLE variable.  While this obviously requires some work,
to me it seems less intrusive than the notion of weak references.

Of course this means that we are keeping the debug information in a
reversed form.  Instead of saying that a user variable is associated
with an expression in terms of GIMPLE variables, we will say that a
GIMPLE variable is associated with an expression in terms of user
variables.  We will have to reverse the latter expression to get the
correct debug information.  Of course in some cases this will be
impossible, as when a GIMPLE variable is associated with a sum of user
variables; presumably in those cases you would have to drop the DEBUG
statement anyhow.

By the way, we shouldn't confuse the source code live range of the
variable with the annotations on the GIMPLE variables.  That will get
us into the mapping of source code lines to optimized code.  It is of
course true that optimized code will move around unpredictably, and
your proposal doesn't handle that.  I don't see it as a flaw that it
will be possible to view user variables outside of their source code
range.

In any case, RTL is different.  We can't reasonably associate
annotations with pseudo-registers, because they change during the
function.  The obvious choices are to annotate SET statements, or to
annotate insns, or to introduce a DEBUG insn as you suggest.  It's not
obvious to me why a DEBUG insn is superior to a REG_NOTE attacked to
an insn.  The problem with DEBUG insns is of course that the RTL code
is very sensitive to new insns, and also the additional memory usage.
You discuss those, but it's not obvious to me why your proposed
solution is the best one.


> Testing for accuracy and completeness of debug information can be best
> accomplished using a debugging environment.

Of course this is very unsatisfactory without an automated testsuite.

Ian