Re: Designs for better debug info in GCC

[Alexandre Oliva <aoliva at redhat dot com>]

On Nov 13, 2007, Michael Matz <matz@suse.de> wrote:

> Hi,
> On Mon, 12 Nov 2007, Alexandre Oliva wrote:

>> With the design I've proposed, it is possible to compute the value of i, 

> No.  Only if the function is reservible.

Of course.  I meant it for that particular case.  The generalization
is obvious, but I didn't mean it would be always possible.

>> As I wrote before, I'm not aware of any systemtap bug report about a
>> situation in which an argument was actually optimized away.

> I think it all started from PR23551.

Yep.  Nowhere does that bug report request parameters to be forced
live.  What it does request is that parameters that are not completely
optimized away be present in debug information.

Now, consider these cases:

1. function is not inlined

At its entry point, we bind the argument to the register or stack slot
in which the argument is live.  Worst case, it's clobbered at the
entry point instruction itself, because it's entirely unused.  By
emitting a live range from the entry point to the death point, we're
emitting accurate and complete debug information for the argument.  We
win.

2. function is inlined, the argument is unused and thus optimized
away, but the function does some other useful computation

At the inlined entry point, we have a note that binds the argument to
its expected value.  As we transform the program and optimize away the
argument, we retain and update the note, such that we can still
represent the value of the inlined argument for as long as it's
available.

3. function is inlined and completely optimized away

No instruction remains in which the argument is in scope, so we might
as well refrain from emitting location information for it.  Even
though we can figure out where the value lives, there's no code to
attach this information to.  So there's no place to set a breakpoint
on to inspect the variable location anyway.

> For us it also happened in the kernel in namei.c, where real_lookup
> is inlined sometimes, and it's arguments are missing.  That might or
> might not be reversible functions, so your scheme perhaps would have
> helped there.  But generally it won't solve the problem for good.

It looks like you're trying to solve a different problem.

I'm not trying to find a way to ensure that arguments are live.

I'm trying to get GCC to emit debug information that correctly matches
the instructions it generated.

If the value of a variable is completely optimized away at a point in
the porogram, the correct representation for its location at that
point is an empty set.

>> I wouldn't go as far as stopping the optimization just so that systemtap 
>> can monitor the code.

> Like I said, at some point you have to or accept that some code remains to 
> be not introspectable.

Yep.  It's easy enough to tweak the code to keep a variable live, if
you absolutely need it.  But this is not something I'm working to get
the compiler to do by itself.  Quite the opposite, in fact.  I'm going
to set the compiler free to perform some optimizations that it
currently refrains from performing for the sake of debug information,
when the conflict is only apparent because of past implementation
decisions that I'm working to fix.

> Then I'm probably still confused what problem you're actually trying to 
> solve.  If you don't want to be sure you get precise location information 
> 100% of the time, then what percentage are you required to get?

Accuracy comes first.  If we ever emit debug information saying 'this
variable is here' for a point in the program in which it's in fact
elsewhere or unavailable, that's a bug to be fixed.

Completeness comes second.  If we could have emitted debug information
saying 'the value of this variable is here' for a point in the
program, and we instead claim the variable is unavailable at that
point, that's an improvement that can be made.

> And how do you measure this?

Good question.  The implementation approach I've taken, that exposes
debug annotations as actual code, starts out with 100% accuracy
(that's the theory, anyway, otherwise generated code would change,
and, even though we still don't have a complete framework to ensure
code doesn't change, if it does, then at least debug information will
model the change accurately), and we can then grow completeness
incrementally.

> Or is the task rather "emit better debug info"?

Nope.  That's a secondary goal that will be achieved as we get
accurate and sufficiently complete debug information.  I don't have
completeness goals set, but I have reasons to expect we're going to
get much better results than we have now without too much additional
effort.

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