Re: Designs for better debug info in GCC

["Daniel Berlin" <dberlin at dberlin dot org>]

On 12/15/07, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Dec  5, 2007, Diego Novillo <dnovillo@google.com> wrote:
>
> > On 11/25/07 3:43 PM, Mark Mitchell wrote:
>
> >> My suggestion (not as a GCC SC member or GCC RM, but just as a fellow
> >> GCC developer with an interest in improving the compiler in the same way
> >> that you're trying to do) is that you stop writing code and start
> >> writing a paper about what you're trying to do.
> >>
> >> Ignore the implementation.  Describe the problem in detail.  Narrow its
> >> scope if necessary.  Describe the success criteria in detail.  Ideally,
> >> the success criteria are mechanically checkable properties: i.e., given
> >> a C program as input, and optimized code + debug information as output,
> >> it should be possible to algorithmically prove whether the output is
> >> correct.
>
> > Yes, please.  I would very much like to see an abstract design
> > document on what you are trying to accomplish.
>
> Other than the ones I've already posted, here's one:
>
> http://dwarfstd.org/Dwarf3Std.php
>
> Seriously.  There is a standard for this stuff.  My ultimate goal in
> this project is that we comply with it
Comply with it how?

There is no portion of the DWARF3 spec which requires you output
information that is correct or useful. The same way the C standard
does not require you to write correct programs, only valid ones, the
DWARF3 spec does not require you to output correct information, only
information that is encoded properly.

It is certainly a goal of DWARF3 to allow producers to provide correct
info (as witness by the one of the listed goals: "Debugging
information must provide consumers a way to find the location of
program variables,  determine the bounds of dynamic arrays and
strings, and possibly to find the base address of a  subroutine's
stack frame or the return address of a subroutine. Furthermore, to
meet the needs of recent computer architectures and optimization
techniques, debugging information must be  able to describe the
location of an object whose location changes over the object's
lifetime.")

If you search the entire spec for the word "correct", you will find it
3 times.  If you search for "must", you will discover they all related
to encoding or the goals of the standard.

It may be entirely useless to output incorrect information, and in
fact, worse than useless.
It is however, compliant, as long as they are encoded properly.

I have to say, this is typical of the argumentation you have used thus
far in this thread, and honestly, it's not winning you any points.

That said, nobody here believes we should output useless or incorrect
info, even though we could.  A lot of people appear to disagree with
you about the best way to do it, and in fact, about what we should be
trying to provide users in what cases.

>
>What part of instrusiveness are you concerned about?  The change of
>INSN_P such that it covers DEBUG_INSN_P too in the supported range?
>Or the few changes that revert to the original INSN_P, in the few
>exceptions in which DEBUG_INSN_P is not to be handled as an INSN?

>I've heard this "intrusiveness" argument be pointed out so many times,
>by so many people that claim to not have been able to keep up with the
>thread, and who claim to have not looked at the patches at all, that
>I'm more and more convinced it's just fear of the unknown than any
>actual rational evaluation of the impact of the changes.

Well, no.
You yourself have shown it to be intrusiveness in the extreme, in the
very next paragraphs!

"
At some point you have to face reality and see that such information
isn't kept around by magic, it takes some effort, and this effort is
needed at every location where there are changes that might affect
debug information.  And that's pretty much everywhere. "

So, everywhere needs to change. That's pretty intrusiveness, no?

"Sure, this might require a little bit more thinking in some
optimizations.  But in my experience fixing up the tree and rtl passes
that needed tweaking, the additional thinking needed is a no-brainer
in most cases; in a few, you have to work a bit harder to keep
information around rather than simply noting it as unavailable. "

Having to stop and think at every point in an optimization about the
debug info, having to deal with debug info at every single point of
change, and then your other patches
This is intrusiveness as well (having to stop and think about debug
info at every single point of every single optimization).

You don't need to be this intrusiveness to stop outputting the
incorrect info we do.


>I've never seen this documented as such, and we've never worked toward
> these stated goals.

Who is we?
I certainly have worked exactly towards these goals.
As have almost all the authors of the current debugging info
framework.  The reason it is the way it is  because these in fact,
*were exactly the goals we were working towards*.
As for not documented, a lot of gcc is not documented.
If you look in the mailing list archives, you will even discover Diego
is not the first one have exactly the viewpoint about what should and
should not be debuggable, and that the community has consistenly
worked towards exactly the viewpoint diego describes.


Anyway, I give up on reading this thread.  It has turned into a mess.
You really need to step back and see that you have not achieved any
sort of consensus of what levels of optimization should be how
debuggable, before you start telling everyone their approach isn't as
good as yours.

I certainly wouldn't agree that we should take such intrusive steps to
make -O2 -g as debuggable as you want,  I'd much rather see us do what
we can easily, and drop any info that ends up being incorrect.