Re: Designs for better debug info in GCC

[Mark Mitchell <mark@codesourcery.com>]

Alexandre Oliva wrote:
> On Nov 12, 2007, Mark Mitchell <mark@codesourcery.com> wrote:
> 
>> Clearly, for some users, incorrect debugging information on optimized
>> code is not a terribly big deal.  It's certainly less important to many
>> users than that the program get the right answer.  On the other hand,
>> there are no doubt users where, whether for debugging, certification, or
>> whatever, it's vitally important that the debugging information meet
>> some standard of accuracy.
> 
> How is this different from a port of the compiler for a CPU that few
> people care about?  That many users couldn't care less whether the
> compiler output on that port works at all doesn't make it any less of
> a correctness issue.

You're again trying to make this a binary-value question.  Why?

Lots of things are "a correctness issue".  But, some categories tend to
be worse than others.  There is certainly a qualitative difference in
the severity of a defect that results in the compiler generating code
that computes the wrong answer and a defect that results in the compiler
generating wrong debugging information for optimized code.

The impact on a user affected by the first problem is likely very
severe: the application does not run correctly.  The impact on a user
affected by the second problem is likely less severe: the debugger
doesn't work as well, or some other external tool doesn't work as well.

Let's put it this way: if a user has to choose whether the compiler will
(a) generate code that runs correctly for their application, or (b)
generate debugging information that's accurate, which one will they choose?

But what's the point of this argument?  It sounds like you're trying to
argue that debug info for optimized code is a correctness issue, and
therefore we should work as hard on it as we would on code-generation
bugs.  I don't find that argument persuasive.  I'd like better debugging
for optimized code, but I'm certainly more concerned that (a) we
generate correct, fast code when optimizing, and (b) we generate good
debugging information when not optimizing.

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