This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Designs for better debug info in GCC

On Nov  8, 2007, Michael Matz <> wrote:

> Hi,
> On Wed, 7 Nov 2007, Alexandre Oliva wrote:

>> > x and y at the appropriate part.  Whatever holds 'x' at a point (SSA 
>> > name, pseudo or mem) will also mention that it holds 'c'.  At a later 
>> > point whichever holds 'y' will also mention in holds 'c' .
>> I.e., there will be two parallel locations throughout the entire 
>> function that hold the value of 'c'.

> No.  For some PC locations the location of 'c' will happen to be the same 
> as the one holding 'x', and for a different set of PC locations it will be 
> the one also holding 'y'.

So we're in agreement.  What you say is how it ought to be done, what
I did was to point out that the representation proposed by richi will
be unable to do the right thing.

>> f(int x /* but also c */, int y /* but also c */) { /* other vars */

> "int x /* but also c */, int y /* but also c */" implies that x == y 
> already

No, per the posted design (assuming I understood it correctly) it just
implies that, at some point in the program, an assignment 'c = x' was
optimized away, and that at some other point in the program, an
assignment 'c = y' was optimized away.

>> do_something_with(x, ...); // doesn't touch x or y
>> do_something_else_with(y, ...); // doesn't touch x or y
>> Now, what will you get if you 'print c' in the debugger (or if any
>> other debug info evaluator needs to tell what the value of user
>> variable c is) at a point within do_something_with(c,...) or
>> do_something_else_with(c)?

> ... so the answer would be "whatever is in that common place for x,y and 
> c".

And once we removed the incorrect assumption you made, that 'x == y',
what do you get?

> How come that f::c is actually set to p$x?

It was in the original source code, was it not?  p$x was passed to f()
as x, and then x was copied to c.

> I don't see any assignment and in fact no declaration for c in f.
> If you had one _that_ would be the place were the connection between
> p$x and 'c' would have been made and everything would fall in place.

Since there is a declaration of c in the original source-level f (the
only one that matters, as far as debug information is concerned), can
you please expand on how you'd get everything to fall in place?

> It's not possible that p$x _and_ p$y are f()::c.1 at the same time,


> so the above examples are all somehow invalid.

It's the bitmap debug info representation that makes them nonsensical.

> int f(int y) {
>   int x = 2 * y;
>   return x + 2;
> }

> If the compiler forward-props 2*y into the single use and simplifies:

>   return (y+1)*2;

> then the value 2*y is never actually calculated anymore, not in any 
> register, not in any local variable, nowhere.  There's no way debug 
> information could generally rectify this loss of information.

Actually, while y is live, debug information could encode that x is
2*y, even if the value is not computed at run time.  So your statement
is quite an exaggeration.

> In case of more complicated expressions that's not possible anymore
> and you lose.

Yep.  If the value is unavailable, debug information should say so,
rather than pointing at something else.

> Forcing some values life is possible,

But undesirable.  I'm not trying to do that.  Actually, I'm working
hard to make sure it doesn't happen.

> So, our mapping is as accurate as your's.

Not at all, and you made that point yourself, twice, in a single

> It seems in your branch you also force some values life IIUC.

Nope.  Any values that are forced live by debug annotations are bugs
to be fixed.

Alexandre Oliva
FSF Latin America Board Member
Red Hat Compiler Engineer   aoliva@{,}
Free Software Evangelist  oliva@{,}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]