From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15706 invoked by alias); 16 Dec 2007 21:28:40 -0000 Received: (qmail 15458 invoked by uid 22791); 16 Dec 2007 21:28:39 -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; Sun, 16 Dec 2007 21:28:29 +0000 Received: (qmail 27227 invoked from network); 16 Dec 2007 21:28:27 -0000 Received: from unknown (HELO ?192.168.0.2?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Dec 2007 21:28:27 -0000 Message-ID: <4765986F.90904@codesourcery.com> Date: Sun, 16 Dec 2007 22:20:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Alexandre Oliva CC: Diego Novillo , Robert Dewar , Ian Lance Taylor , 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> <4737BF2C.70408@codesourcery.com> <47388599.2040701@codesourcery.com> <4749DE66.1090602@codesourcery.com> <4756B02D.9010302@google.com> In-Reply-To: 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-12/txt/msg00480.txt.bz2 Alexandre Oliva wrote: >> Yes, please. I would very much like to see an abstract design >> document on what you are trying to accomplish. > > Other than the ones I've already posted, here's one: > > http://dwarfstd.org/Dwarf3Std.php > > Seriously. There is a standard for this stuff. That's the specification for the encoding format. I agree with you that emitting incorrect debugging information, in the sense of declaring that the location of a variable is in one place, even though its value is not available in that place, is bad. In -O0 code, I consider it a serious bug. In -O2 code, I think it's still a bug, but with our current infrastructure, we may have little choice: we either deny all knowledge of the variable's location, or give one that's sometimes incorrect. Which alternative is better depends on what you're trying to do with the information; for interactive debugging, mostly-right is probably better than nothing, whereas for some programmatic activities, the opposite may be true. If your goal is to avoid the information ever being wrong -- without worrying about whether it is complete -- there is of course a trivial solution: do not emit the information. That is not a serious suggestion, but it does provide a path to a serious suggestion, which I gave earlier: conservatively emit location information you provide based on what you can prove at the time you generate debugging information. For example, if the value of "x" is in a register, and you cross a call which might clobber that register value, then emit debugging information that says that at that point the value is unavailable. You could probably do this kind of thing with relatively few changes to the GCC internal representation; you would run a pass before debug-information generation that attempted to prove dataflow properties about variables and told you where values could reliably be found. Your earlier messages, however, suggest that you are trying to do something harder: emit information that is essentially both complete (in the sense of providing as much information as possible about the locations and values of variables) and correct (in the sense of never giving incorrect information). If you want to do that, you're going to have to answer the harder questions, like "what line number corresponds to this address?" and "what should the debugging information say that the value of a variable is when it has been optimized away?" If that's still your goal, then pointing at the DWARF3 specification doesn't help. Diego and I are asking you to confront these fundamental questions about what information you want to provide and what the correctness criteria are. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713