From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25406 invoked by alias); 8 Nov 2007 08:58:56 -0000 Received: (qmail 25397 invoked by uid 22791); 8 Nov 2007 08:58:55 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 Nov 2007 08:58:53 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iq3Df-000635-3O for gcc-patches@gcc.gnu.org; Thu, 08 Nov 2007 08:58:35 +0000 Received: from usilu-ge.ti-edu.ch ([195.176.176.226]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Nov 2007 08:58:35 +0000 Received: from bonzini by usilu-ge.ti-edu.ch with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Nov 2007 08:58:35 +0000 To: gcc-patches@gcc.gnu.org From: Paolo Bonzini Subject: Re: Designs for better debug info in GCC Date: Thu, 08 Nov 2007 08:58:00 -0000 Message-ID: References: <84fc9c000711050327x74845c78ya18a3329fcf9e4d2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) In-Reply-To: Cc: gcc@gcc.gnu.org X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg00393.txt.bz2 > What standards are you talking about? I'm not aware of any standard > for debuggability of optimized code. As a developer of gcc, it would be *invaluable* in debugging for example bootstrap comparison failures. There I have to debug side-by-side the stage1 and the stage2 compiler, and no way I can compile the latter unoptimized... As a user more than a developer of gcc this days, definitely yes. I often have programs that run for say 1 minute, and I *know* the bug comes up after 50 seconds. It's already unnerving enough to debug programs like this (I often start ten gdbs at the same time, launch them to the magic point while I'm taking a coffee, and go back working!); and it's only worse if you're doing it on -O0 binaries that take 5 minutes to reach the point you're trying to debug. Backward debugging would also be a possibility for me, much more productive than debuggability of optimized code, but since backward debugging is pie-in-the-sky, debuggability of optimized code is also good. Paolo