Re: Designs for better debug info in GCC

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 18 Dec 2007 08:13:55 -0800, Ian Lance Taylor <iant@google.com> wrote:
> 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.

Indeed.

>
> > == 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.

This is what we do on the var-mappings-branch.  One obvious thing is
that SSA form doesn't help you to track the reverse of VAR = cst.  But
of course it's easy to do another reverse mapping from constants to vars.

A similar reverse mapping can be done for SET insns on RTL.

> 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.

I think this is where Alexandes approach _might_ work.  (It at least
produces loads of funny DEBUG_INSNs ...)  I chose to ignore this
problem and say we debug the optimized program, not the source
as far as life ranges are concerned.

> 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

We "annotate" SET insns by adding a bitmap argument to track user
variables it sets.  That seems to work nicely.

> 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.

I was thinking of pulling in the gdb testsuite harness into gcc...

Richard.