From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5770 invoked by alias); 23 Nov 2007 23:40:47 -0000 Received: (qmail 5647 invoked by uid 22791); 23 Nov 2007 23:40:45 -0000 X-Spam-Check-By: sourceware.org Received: from lsd-gw.ic.unicamp.br (HELO marquesa.lsd.ic.unicamp.br) (143.106.7.165) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 23 Nov 2007 23:40:37 +0000 Received: from freie.oliva.athome.lsd.ic.unicamp.br (gw-to-emilia.oliva.athome.lsd.ic.unicamp.br [172.31.160.17] (may be forged)) by marquesa.lsd.ic.unicamp.br (8.14.1/8.14.1) with ESMTP id lANNe1aC028408; Fri, 23 Nov 2007 21:40:03 -0200 Received: from livre.oliva.athome.lsd.ic.unicamp.br (livre.oliva.athome.lsd.ic.unicamp.br [172.31.160.2]) by freie.oliva.athome.lsd.ic.unicamp.br (8.14.1/8.14.1) with ESMTP id lANNe0Lg005026; Fri, 23 Nov 2007 21:40:01 -0200 Received: from livre.oliva.athome.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by livre.oliva.athome.lsd.ic.unicamp.br (8.14.2/8.13.8) with ESMTP id lANNe0Ks025760; Fri, 23 Nov 2007 21:40:00 -0200 Received: (from aoliva@localhost) by livre.oliva.athome.lsd.ic.unicamp.br (8.14.2/8.13.5/Submit) id lANNe0te025759; Fri, 23 Nov 2007 21:40:00 -0200 To: Michael Matz Cc: Robert Dewar , 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> <47331636.9010308@adacore.com> From: Alexandre Oliva Errors-To: aoliva@lsd.ic.unicamp.br Date: Sat, 24 Nov 2007 04:58:00 -0000 In-Reply-To: (Michael Matz's message of "Tue\, 13 Nov 2007 13\:14\:35 +0100 \(CET\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00598.txt.bz2 On Nov 13, 2007, Michael Matz wrote: > Hi, > On Mon, 12 Nov 2007, Alexandre Oliva wrote: >> With the design I've proposed, it is possible to compute the value of i, > No. Only if the function is reservible. Of course. I meant it for that particular case. The generalization is obvious, but I didn't mean it would be always possible. >> As I wrote before, I'm not aware of any systemtap bug report about a >> situation in which an argument was actually optimized away. > I think it all started from PR23551. Yep. Nowhere does that bug report request parameters to be forced live. What it does request is that parameters that are not completely optimized away be present in debug information. Now, consider these cases: 1. function is not inlined At its entry point, we bind the argument to the register or stack slot in which the argument is live. Worst case, it's clobbered at the entry point instruction itself, because it's entirely unused. By emitting a live range from the entry point to the death point, we're emitting accurate and complete debug information for the argument. We win. 2. function is inlined, the argument is unused and thus optimized away, but the function does some other useful computation At the inlined entry point, we have a note that binds the argument to its expected value. As we transform the program and optimize away the argument, we retain and update the note, such that we can still represent the value of the inlined argument for as long as it's available. 3. function is inlined and completely optimized away No instruction remains in which the argument is in scope, so we might as well refrain from emitting location information for it. Even though we can figure out where the value lives, there's no code to attach this information to. So there's no place to set a breakpoint on to inspect the variable location anyway. > For us it also happened in the kernel in namei.c, where real_lookup > is inlined sometimes, and it's arguments are missing. That might or > might not be reversible functions, so your scheme perhaps would have > helped there. But generally it won't solve the problem for good. It looks like you're trying to solve a different problem. I'm not trying to find a way to ensure that arguments are live. I'm trying to get GCC to emit debug information that correctly matches the instructions it generated. If the value of a variable is completely optimized away at a point in the porogram, the correct representation for its location at that point is an empty set. >> I wouldn't go as far as stopping the optimization just so that systemtap >> can monitor the code. > Like I said, at some point you have to or accept that some code remains to > be not introspectable. Yep. It's easy enough to tweak the code to keep a variable live, if you absolutely need it. But this is not something I'm working to get the compiler to do by itself. Quite the opposite, in fact. I'm going to set the compiler free to perform some optimizations that it currently refrains from performing for the sake of debug information, when the conflict is only apparent because of past implementation decisions that I'm working to fix. > Then I'm probably still confused what problem you're actually trying to > solve. If you don't want to be sure you get precise location information > 100% of the time, then what percentage are you required to get? Accuracy comes first. If we ever emit debug information saying 'this variable is here' for a point in the program in which it's in fact elsewhere or unavailable, that's a bug to be fixed. Completeness comes second. If we could have emitted debug information saying 'the value of this variable is here' for a point in the program, and we instead claim the variable is unavailable at that point, that's an improvement that can be made. > And how do you measure this? Good question. The implementation approach I've taken, that exposes debug annotations as actual code, starts out with 100% accuracy (that's the theory, anyway, otherwise generated code would change, and, even though we still don't have a complete framework to ensure code doesn't change, if it does, then at least debug information will model the change accurately), and we can then grow completeness incrementally. > Or is the task rather "emit better debug info"? Nope. That's a secondary goal that will be achieved as we get accurate and sufficiently complete debug information. I don't have completeness goals set, but I have reasons to expect we're going to get much better results than we have now without too much additional effort. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}