From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23147 invoked by alias); 5 Dec 2007 22:10:51 -0000 Received: (qmail 23125 invoked by uid 22791); 5 Dec 2007 22:10:49 -0000 X-Spam-Check-By: sourceware.org Received: from us01smtp2.synopsys.com (HELO kiruna.synopsys.com) (198.182.44.80) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Dec 2007 22:10:42 +0000 Received: from mother.synopsys.com (mother.synopsys.com [146.225.100.171]) by kiruna.synopsys.com (Postfix) with ESMTP id 216C2FE95; Wed, 5 Dec 2007 14:10:40 -0800 (PST) Received: from piper.synopsys.com (localhost [127.0.0.1]) by mother.synopsys.com (8.9.1/8.9.1) with ESMTP id OAA18535; Wed, 5 Dec 2007 14:10:39 -0800 (PST) Received: from piper.synopsys.com (localhost [127.0.0.1]) by piper.synopsys.com (8.12.11/8.12.3) with ESMTP id lB5MAdnS031731; Wed, 5 Dec 2007 14:10:39 -0800 Received: (from jbuck@localhost) by piper.synopsys.com (8.12.11/8.12.11/Submit) id lB5MAZhS031729; Wed, 5 Dec 2007 14:10:35 -0800 Date: Wed, 05 Dec 2007 22:10:00 -0000 From: Joe Buck To: Diego Novillo Cc: Mark Mitchell , Alexandre Oliva , 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 Message-ID: <20071205221035.GB31543@synopsys.com> References: <4733A637.8070004@adacore.com> <4737BF2C.70408@codesourcery.com> <47388599.2040701@codesourcery.com> <4749DE66.1090602@codesourcery.com> <4756B02D.9010302@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4756B02D.9010302@google.com> User-Agent: Mutt/1.4.1i 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/msg00135.txt.bz2 On Wed, Dec 05, 2007 at 09:05:33AM -0500, Diego Novillo wrote: > In my simplistic view of this problem, I've always had the idea that -O0 > -g means "full debugging bliss", -O1 -g means "tolerable debugging" > (symbols shouldn't disappear, for instance, though they do now) and -O2 > -g means "you can probably know what line+function you're executing". I'd be happy enough if the state of -O1 -g debugging were improved, perhaps using some of Alexandre's ideas so that it could be "full debugging bliss" with some optimization as well. Speeding up the compile/test/debug/modify cycle would result. We could then have fast but fully debuggable code at -O1, and even faster code at -O2 not constrained by the requirement of, as Diego says, "deconstructing arbitrary transformations done by the optimizers".