Re: Designs for better debug info in GCC

[Alexandre Oliva <aoliva@redhat.com>]

On Nov  8, 2007, Ian Lance Taylor <iant@google.com> wrote:

> However, I don't think your arguments that this is
> an issue comparable to code correctness are valid.

It *is* code correctness.  Say, if the linker emitted incorrect
addresses in an executable, but the kernel and dynamic loader didn't
rely on those addresses, would it not still be a bug in the linker?
And then, if those tools started relying on those addresses and
exposed the problem, would it be right to tell them they must not rely
on them because they were broken in the past and we don't feel like
correcting the linker?

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?

> Incorrect generated code is a fatal problem in a compiler.
> Incorrect debugging information is a quality of implementation
> issue.

Incomplete debugging information is a quality of implementation, just
like missed optimizations.

Incorrect compiler output is a bug.  Claiming it's not just because
tools you happen to rely on don't care about that piece of information
won't make it any less of a bug.  It may make it a less important bug
for some time, but it's still a bug.


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

All notes (as in matching NOTE_P) I remember didn't really contain rtx
expressions.  The first exception I remember is VAR_LOCATION, and this
one explicitly does *not* want to be updated, for it's generated so
late in the process.

Conversely, REG_NOTES do contain rtx, and they often have to be
updated, so that's the right representation for them.  Do you think
we'd gain anything by moving them to a separate, out-of-line
representation?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}