On 11/8/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> 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.
I think we're going to find out once both approaches are implemented up to a
way that they reasonably to what they want to do. So I'm fine to defer this
decision up to that point (or the point where we start the fighting on which
approach will get merged).
> 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?
For the example above, the representation we use on the tree level cannot
attach a name to '3' (since obviously '3' is not a SSA_NAME). But this is
fixable if we think it is worthwhile.
> 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.
That's true. I was also thinking on how to properly do testcases for both kind
of infrastructure. At the moment I scan tree/rtl dumps for the names I want
to preserve, but ultimately it would be nice to be able to run gdb testcases in
the gcc tree to also verify 'correctness' of the information we produce (and
not just existence of some information).
Richard.
