From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28740 invoked by alias); 12 Nov 2007 02:49:34 -0000 Received: (qmail 28716 invoked by uid 22791); 12 Nov 2007 02:49:33 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 12 Nov 2007 02:49:31 +0000 Received: (qmail 6845 invoked from network); 12 Nov 2007 02:49:29 -0000 Received: from unknown (HELO ?192.168.0.2?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Nov 2007 02:49:29 -0000 Message-ID: <4737BF2C.70408@codesourcery.com> Date: Mon, 12 Nov 2007 12:59:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Robert Dewar CC: Ian Lance Taylor , Alexandre Oliva , Richard Guenther , gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Designs for better debug info in GCC References: <84fc9c000711050327x74845c78ya18a3329fcf9e4d2@mail.gmail.com> <4733A637.8070004@adacore.com> In-Reply-To: <4733A637.8070004@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg00299.txt.bz2 Robert Dewar wrote: > Ian Lance Taylor wrote: >> Alexandre Oliva writes: >> >>> So... The compiler is outputting code that tells other tools where to >>> look for certain variables at run time, but it's putting incorrect >>> information there. How can you possibly argue that this is not a code >>> correctness issue? >> >> I don't see any point to going around this point again, so I'll just >> note that I disagree. > > Well I very much agree. The trick is that we're being asked to give a binary answer ("is it a correctness issue?") when it's not really a binary issue. Clearly, for some users, incorrect debugging information on optimized code is not a terribly big deal. It's certainly less important to many users than that the program get the right answer. On the other hand, there are no doubt users where, whether for debugging, certification, or whatever, it's vitally important that the debugging information meet some standard of accuracy. Part of my concern with this whole discussion is that we seem to be saying we want the debugging information to be better, but not saying very clearly what the requirements on better are. Are we going to consider it a bug if the value of a variable is unavailable, but the debugging information says it is available? (Yes, this seems like a bug to me.) What if an old value is available, but a simple-minded reading of the program would have now assigned a new value? (No, I wouldn't consider this a bug.) What if the value is available in two places, and we only describe one of them? (No, I wouldn't consider this a bug.) What if the value is available, but we say that it isn't because we lost track of it at some point? (I would say "it depends".) We could certainly track user variables through SSA and RTL, at least insofar as knowing that some REGs refer to SSA names that refer to user VAR_DECLs. We can use dataflow analysis to compute where those values (might) die. Thus, we can probably do a reasonable job of guaranteeing that when we say a variable is somewhere, it is in fact in that place. I don't yet understand what else we're trying to do. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713