Re: Ping 5! [PATCH, revised]: Track uninitialized variables

[Caroline Tice <ctice at apple dot com>]

Mark Mitchell wrote:
>
> I've looked at this patch a few times.  To be honest, the reasons  
I've
> never tried to review it is that (a) it's big, and (b) I'm not sure
> *why* we want it, (c), the archives and (c) I was secretly hoping Ian
> would review it since he'd had some comments before.
>
> Would you please address (b)?  What does having this information  
in the
> debugger allow you to do?  Is it that it helps you debug because  
you can
> tell "uninitialized" from "random weird value"?
>

This is part of some work I have been doing for improving debugging
optimized code.  Sometimes bugs that seem to "magically appear"
when optimizations get turned on are actually caused by uninitialized
variables having a different value when the optimizations change
the data layout.  In the unoptimized version the value happened
to be benign, but in the optimized version the value causes bad
things to happen.  Therefore it would help programmers quite
a bit, when attempting to debug optimized code, if the
debugger could point out when a variable did not get initialized.

(Yes, I know there is a gcc warning option that warns about  
uninitialized
variables, but sometimes users don't compile with that option turned  
on, or the
person doing the debugging isn't the person who did the compilation, or
re-compiling really isn't an option for some other reason.  Or the  
person
debugging hasn't considered that a variable might be uninitialized...

>
> Also, what's the memory impact of this patch, given that it makes
> VAR_LOCATION bigger?
>

I am not sure what the impact is.  My guess is that the impact is not  
very
much, but that is just a guess.  If you could suggest a good way to  
measure
this, I will be happy to do so and report the results.

>
> Why is this target specific?  Do non-GNU debuggers do something  
bad if
> they see DW_OP_GNU_uninit?  If so, do we have to worry about older
> versions of GDB?
>

DW_OP_GNU_uninit is a DWARF extension, i.e. it is non-standard, so any
debugger that is not specifically  modified to handle it may have a   
problem.
The exact nature of the problem depends on how the particular debugger
handles unrecognized DWARF.

The revised patch I submitted removed target-specificity and put this
under the control of a command line option, which defaults to off, since
I don't want to turn it on by default for users who do not have a
debugger that can handle it.   I have turned in on by default for Darwin
 MacOS  X 10.5 because I know the gdb that comes with that can handle
this Dwarf op.

Also, GNU GDB accepted a patch to handle this op about a month ago,
so anybody using the latest build of GNU GDB should be fine.

>
> Does the new dataflow machinery give us any way to get the  
information
> more easily?  Like, can we just ask it about a REG from
> one_reg_loc_descriptor, rather than having to pass information around
> through multiple functions?
>

I have not looked at the new dataflow machinery;  I will have to  
investigate this
and get back to you on it. (If anyone more familiar with the new  
dataflow stuff
can answer this question, please do!).  :-)

-- Caroline Tice
ctice@apple.com