Re: Designs for better debug info in GCC

[Michael Matz <matz at suse dot de>]

Hi,

On Fri, 23 Nov 2007, Alexandre Oliva wrote:

> Yep.  Nowhere does that bug report request parameters to be forced live.  

Not in that bug report perhaps, but we got requests for exactly this, i.e. 
to be able to introspect all parameters of all functions, be they inlined 
or not, at all time.  I think that's a reasonable request even (which in 
some situations comes at a cost).

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

As far as possible.  If it's not possible you loose (with our 
requirements).

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

We work on two fronts:
1) increasing the precision of debug information
2) forcing values life

Our branch, and our ssa-name<->user-name map (and the SET<->decls 
association) is concerned with the first topic.  The second topic can be 
implemented (or hacked) already now, but will potentially be more usefull 
when we also have (1).  So, as in your branch, we are not trying to limit 
optimizers to reach the goal, that's the concern of (2), and happens 
somewhere else.

> 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 think this is academic.  If a value is dead, but happens to lie in a 
place which isn't yet overwritten with something else, it is harmless to 
reveal this value.  It's the "last" value the variable had.  If OTOH the 
place _is_ already overwritten then it's important that we _don't_ say the 
dead variable lies therein.

So, for me correctness is defined a bit different than for you:
1) if location L contains value X, then debug info should say so (as much 
   as possible, i.e. here the quality of the info comes into play)
2) if location L does not contain value X, debug info should not say that 
   it does.  This is the correctness part.

Where we differ in opinion (I think) is, when location L doesn't contain 
value X anymore.  For you it's when X becomes dead.  For me it's when X is 
dead and when location L is overwritten (with something different than X).  
I think for users there is no practical difference between our approaches, 
but there's a higher cost of implementation for your definition.

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

I agree here ...

> or unavailable, that's a bug to be fixed.

... and disagree here.  If a value is dead it's not necessarily 
unavailable in my world.  I think a world requiring this (and hence the 
constraints you were given) is unreasonable.


Ciao,
Michael.