This is the mail archive of the gcc-patches@gcc.gnu.org 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 <matz@suse.de> 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,

Exactly

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

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


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