On 18 Dec 2007 08:13:55 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Alexandre Oliva <[EMAIL PROTECTED]> writes: > > > A plan to fix local variable debug information in GCC > > > > by Alexandre Oliva <[EMAIL PROTECTED]> > > > > 2007-12-18 draft > > Thank you for writing this. It makes an enormous difference.
Indeed. > > > == Goals > > I note that you don't say anything about the other big problem with > debugging optimized code, which is that the debugger jumps around all > over the place. That is fine, of course. > > > > Once this is established, a possible representation becomes almost > > obvious: statements (in trees) or instructions (in rtl) that assert, > > to the variable tracker, that a user variable or member is represented > > by a given expression: > > > > # DEBUG var expr > > > > By var, we mean a tree expression that denotes a user variable, for > > now. We envision trivially extending it to support components of > > variables in the future. > > While you say that this is almost obvious, it still isn't obvious at > all to me. You consider trees and RTL together, but I don't see why > that is appropriate. > > My biggest concern at the tree level is the significantly increased > memory usage and the introduction of a sort of a weak pointer to > values. Since DEBUG statements shouldn't interfere with > optimizations, we need to explicitly ignore them in things like > has_single_use. But since our data structures need to be coherent, we > can not ignore them when we actually eliminate SSA names. That seems > sort of complicated. > > In SSA form it seems very natural to provide a set of associations > with user variables for each GIMPLE variable. Since the GIMPLE > variables never change, these associations never change. We have to > get them right when we create a new GIMPLE variable and when we > eliminate a GIMPLE variable. While this obviously requires some work, > to me it seems less intrusive than the notion of weak references. This is what we do on the var-mappings-branch. One obvious thing is that SSA form doesn't help you to track the reverse of VAR = cst. But of course it's easy to do another reverse mapping from constants to vars. A similar reverse mapping can be done for SET insns on RTL. > By the way, we shouldn't confuse the source code live range of the > variable with the annotations on the GIMPLE variables. That will get > us into the mapping of source code lines to optimized code. It is of > course true that optimized code will move around unpredictably, and > your proposal doesn't handle that. I don't see it as a flaw that it > will be possible to view user variables outside of their source code > range. I think this is where Alexandes approach _might_ work. (It at least produces loads of funny DEBUG_INSNs ...) I chose to ignore this problem and say we debug the optimized program, not the source as far as life ranges are concerned. > In any case, RTL is different. We can't reasonably associate > annotations with pseudo-registers, because they change during the > function. The obvious choices are to annotate SET statements, or to > annotate insns, or to introduce a DEBUG insn as you suggest. It's not We "annotate" SET insns by adding a bitmap argument to track user variables it sets. That seems to work nicely. > obvious to me why a DEBUG insn is superior to a REG_NOTE attacked to > an insn. The problem with DEBUG insns is of course that the RTL code > is very sensitive to new insns, and also the additional memory usage. > You discuss those, but it's not obvious to me why your proposed > solution is the best one. > > > > Testing for accuracy and completeness of debug information can be best > > accomplished using a debugging environment. > > Of course this is very unsatisfactory without an automated testsuite. I was thinking of pulling in the gdb testsuite harness into gcc... Richard.
