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: [PATCH]: Track uninitialized variables

On May 8, 2007, at 5:28 PM, Ian Lance Taylor wrote:

Caroline Tice <> writes:

As part of some work I've been doing on improving debugging of
optimized code, I
have developed the following patch which, while tracking the locations
of variables,
also keeps track of whether the variables are initialized or not (it
makes conservative
assumptions where it can't be sure). For those places where it is
sure the variables
are unintialized, it adds an annotation to the var_location_note,
which the dwarf
writer later translates to a new DW_OP (an extension) that indicates a
variable is uninitialized

[ For some reason the line breaks in your e-mail message make it hard to read. ]

I'm sorry about that; I forgot that the our email system does this
sometimes.  I will try to be more careful with future messages.

Can you explain why this is useful?

As I mentioned, this is mostly for help with 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 their optimized code, if the debugger could point out when a variable did not get optimized.

Your patch needs comments for the changes in rtl.def and dwarf2.h.

Okay, will do.

Using TARGET_DWARF_UNINIT_VARS doesn't make sense to me.  This is an
enhancement which depends on the version of gdb being used.  It is not
in any meaningful way target specific.  I would recommend controlling
this via an option.  For Darwin, you can make the option default to on
if you like.

I did it this way on the recommendation of Geoff Keating (we discussed
both approaches), but I am willing to change it if you really want me to.
Geoff's idea, I believe, was that doing it this way, individual people
maintaining their systems can turn this on as they install the correct
version of GDB, then never have to worry about it again, as opposed to
having to pass a flag/option every time you do a compilation. But I may
have misunderstood his reasoning; perhaps he could explain it better.


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