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

[Caroline Tice <ctice at apple dot com>]

I've done a bit more investigation, and now have the answers to
your other questions  (see below).

On Jun 25, 2007, at 3:30 PM, Caroline Tice wrote:
> 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.


I have measured the memory impact (with some help from Eric
Christopher), and found the following:

Measuring the memory impact on compiling the files that make up cc1, I
found that


1). If you do not pass the flag to turn on this feature
(-fvar-tracking-uninit), the memory usage difference is so small as to
be noise (10-20 bytes out of 1.5-2 Megabytes).

2).  If you pass the flag to turn on this feature, the memory usage
increased on the order of 0.005% to 0.01% (i.e. it went up by a little
over 1 Kb out of 1.6 to 2.3 Mb.

This seems to me to be small enough to be acceptable, but of course
that is not my decision to make.

> >
> > 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!).  :-)


I've investigated this a bit further and found that the new dataflow
machinery is not helpful in this particular case.  While it does
provide for tracking some uninitialized variables, it only tracks
uninitialized *register* variables.  It does not identify
uninitialized stack or heap variables.  That could be overcome by
writing a bit more code (taking advantage of the existing code and
framework).  What cannot be overcome is that the dataflow machinery
goes away in pass_df_finish, while this variable location debug
information is output in the middle of pass_final, which is several
passes later.  So no, the new machinery does not give any easier way
to get this information when we need it (because we need it so very
late in the compilation process).  Unless I am misunderstanding
something about the way the new stuff works, which is quite possible.
:-)


-- Caroline Tice
ctice@apple.com