From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9057 invoked by alias); 18 Dec 2007 16:22:33 -0000 Received: (qmail 9036 invoked by uid 22791); 18 Dec 2007 16:22:33 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Dec 2007 16:22:23 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 6E4DB2A95CE; Tue, 18 Dec 2007 11:22:21 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MdjQeTxZ40oc; Tue, 18 Dec 2007 11:22:21 -0500 (EST) Received: from [127.0.0.1] (nile.gnat.com [205.232.38.5]) by rock.gnat.com (Postfix) with ESMTP id CA8C32A95CC; Tue, 18 Dec 2007 11:22:20 -0500 (EST) Message-ID: <4767F3B4.4020709@adacore.com> Date: Tue, 18 Dec 2007 16:28:00 -0000 From: Robert Dewar User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ian Lance Taylor CC: Alexandre Oliva , gcc@gcc.gnu.org Subject: Re: Designs for better debug info in GCC References: <4737BF2C.70408@codesourcery.com> <47388599.2040701@codesourcery.com> <4749DE66.1090602@codesourcery.com> <4756B02D.9010302@google.com> <4aca3dc20712151903r46c9eceane35edb92d08240ac@mail.gmail.com> <4aca3dc20712161712w1133fb96qd66be0e9a0bb1716@mail.gmail.com> <4766B8E5.60500@google.com> <4766DF5C.1020802@google.com> <47671BF4.5050704@google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/msg00525.txt.bz2 Ian Lance Taylor wrote: > Alexandre Oliva writes: > >> A plan to fix local variable debug information in GCC >> >> by Alexandre Oliva >> >> 2007-12-18 draft > > Thank you for writing this. It makes an enormous difference. > > >> == Goals > > I note that you don't say anything about the other big problem with > debugging optimized code, which is that the debugger jumps around all > over the place. That is fine, of course. I don't think it is fine, we have constant complaints from our users about this. I think we definitely need an optimization level that avoids this.