Re: Designs for better debug info in GCC

["Seongbae Park (박성배, 朴成培)" <seongbae dot park at gmail dot com>]

I think both sides are talking over each other, partially because two
different goals are in mind.
IMHO, there are two extremes when it comes to the so called debugging
optimized code.

One camp wants the full debuggability (let's call them debuggability
crowd) - which means
they want to know the value of any valid program state anywhere, and
wants to set breakpoint anywhere
and be able to even change the program state anywhere as if there was
an assignment at the point
the debugger stopped the program at. This camp still wants better
performance (like everyone else)
but they don't want to sacrifice the debuggability for performance,
because they rely on these.

The other camp is the performance crowd, where they want the absolute
best performance
but they still want as much debug information possible. Most people
fall in this camp
and this is what gcc has implemented. This camp doesn't want to change the code
so that they can get better debugging information.

Of course, the real world is somewhere in between, but in practice,
most people fall in the latter group
(aka performance crowd).
Alexandre's proposal would make it possible to make the debuggability
crowd happy
at some unknown cost of compile-time/runtime cost and maintenance cost.

Richiard's proposal (from what I can understand)
would make performance crowd happy, since it would be
less costly to implement than Alexandre's and would provide
incrementally better debugging information
than current,
but it doesn't seem to be that it would make the debuggability crowd happy
(or at least the extremists among debuggability crowd).

So I think the difference in the opinion isn't so much as Alexandre's
proposal is good or bad,
but rather whether we aim to make the debuggability crowd happy or the
performance crowd happy
or both.
Ideally we should serve both groups of users,
but there's non-trivial ongoing maintenance cost for having two
different approaches.

So I'd like to ask both Alexandre and Richard
whether they each can satisfy the other camp,
that is, Alexandre to come up with a way to tweak his proposal so that
it is possible to keep the compile time cost comparable to what is
right now with similar or  better debug information,
and with reasonable maintenance cost,
and Richard whether his proposal can satisfy the debuggability crowd.
Of course, another possible opinion would be to ignore the debuggability crowd
on the ground that they are not important or big.
I personally think it's a mistake to do so, but you may disagree on that point.

Seongbae

On 08 Nov 2007 12:50:17 -0800, Ian Lance Taylor <iant@google.com> wrote:
> Alexandre Oliva <aoliva@redhat.com> writes:
>
> > So...  The compiler is outputting code that tells other tools where to
> > look for certain variables at run time, but it's putting incorrect
> > information there.  How can you possibly argue that this is not a code
> > correctness issue?
>
> I don't see any point to going around this point again, so I'll just
> note that I disagree.
>
>
> > >> >> > We've fixed many many bugs and misoptimizations over the years due to
> > >> >> > NOTEs.  I'm concerned that adding DEBUG_INSN in RTL repeats a mistake
> > >> >> > we've made in the past.
> > >> >>
> > >> >> That's a valid concern.  However, per this reasoning, we might as well
> > >> >> push every operand in our IL to separate representations, because
> > >> >> there have been so many bugs and misoptimizations over the years,
> > >> >> especially when the representation didn't make transformations
> > >> >> trivially correct.
> > >>
> > >> > Please don't use strawman arguments.
> > >>
> > >> It's not, really.  A reference to an object within a debug stmt or
> > >> insn is very much like any other operand, in that most optimizer
> > >> passes must keep them up to date.  If you argue for pushing them
> > >> outside the IL, why would any other operands be different?
> >
> > > I think you misread me.  I didn't argue for pushing debugging
> > > information outside the IL.  I argued against a specific
> > > implementation--DEBUG_INSN--based on our experience with similar
> > > implementations.
> >
> > Do you remember any other notes that contained actual rtx expressions
> > and expected optimization passes to keep them accurate?
>
> No.
>
> > Do you think
> > we'd gain anything by moving them to a separate, out-of-line
> > representation?
>
> I don't know.  I don't see such a proposal on the table, and I don't
> have one myself, so I don't know how to evaluate it.
>
> Ian
>



-- 
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";