Re: Designs for better debug info in GCC

[Mark Mitchell <mark at codesourcery dot com>]

Ian Lance Taylor wrote:

> At one time, gcc actually provided better debugging of optimized code
> than any other compiler, though I don't know if that is still true.
> Optimized gcc code is still debuggable today.  I do it all the time.
> (For me poor support for debugging C++ is a much bigger issue, though
> I think that is an issue more with gdb than with gcc.)

I think we all agree that providing better debugging of optimized code
is a priori a good thing.  So, as I see it, this thread is focused on
what internal representation we might use for that.

I don't know that there's an abstract right answer to whether something
NOTE-like or something on the side is better.  There are problems with
both approaches.  We know the NOTE/DEBUG_INSN thing is going to break,
from experience; we also know the on-the-side thing is going to be hard
to maintain.

Alexandre has clearly thought about this a lot.  I'd like to start by
capturing the functional changes that we want to make to GCC's debug
output -- not the changes that we want in the debug experience, or
changes that we need in GDB, but the changes in the generated DWARF.

For example, I'm thinking of a series of function test cases.  Ignore
the substance of this example -- I'm making it up! -- I'm just trying to
capture the form.

===
int main () { int i; i = 3; return i; }

When optimizing, "i" is optimized away.  The debug info for "i" right
before the return statement says "i has been optimized away", but not
what its value is.  I think it should say that the value is "3".  To do
that, we need to emit a DW_Now_My_Value_is_3 tag for "i".
===

Now, how is whatever representation we pick going to get us that?  Is
the Oliva representation sufficient?  What about the Guenther/Matz
representation?  Independently of the representation, what algorithms
are we going to use to track whatever we need to track as the optimizers
remove, insert, duplicate, and reorder code?

Until we all know what we're trying to do, I don't see how we can make a
good decision about the representation.  Clearly, in the abstract, we
can represent data either on-the-side or in the instruction stream, but
until we know what output we want, I'm not sure how we can pick.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713