From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13719 invoked by alias); 24 Nov 2007 21:24:37 -0000 Received: (qmail 13699 invoked by uid 22791); 24 Nov 2007 21:24:36 -0000 X-Spam-Check-By: sourceware.org Received: from VLSI1.ULTRA.NYU.EDU (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org (qpsmtpd/0.31) with SMTP; Sat, 24 Nov 2007 21:24:32 +0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA08450; Sat, 24 Nov 07 16:23:53 EST From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10711242123.AA08450@vlsi1.ultra.nyu.edu> Date: Sat, 24 Nov 2007 22:42:00 -0000 To: aoliva@redhat.com Subject: Re: Designs for better debug info in GCC Cc: Joe.Buck@synopsys.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org, iant@google.com, mark@codesourcery.com, richard.guenther@gmail.com In-Reply-To: References: <4732519C.6070802@codesourcery.com> <4733554D.4040402@codesourcery.com> <4737BBBF.3080400@codesourcery.com> <20071112180518.GA29269@synopsys.com> X-IsSubscribed: yes 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/msg00619.txt.bz2 > The piece of the puzzle we're still missing is how to get debuggers > clever enough to decide where to set a breakpoint. Nowadays, debuggers > (at least those I'm familiar with) tend to set breakpoints at the > lowest-numbered PC corresponding to a given source line number. While > this is useful at times, at other times what you want is the lowest PC > after all instructions corresponding to the previous line, because at > that point you know all the state of the previous line should be stable > and hopefully still observable. Or something along these lines. I don't > have a complete solution for this problem. It's very far from trivial, > and I don't see that debug information can carry enough information for > the compiler to aid the debugger in selecting where to place breakpoints > in this regard. Or you want the first instruction of that line that shows the actual flow of control. Or sometimes other things, as you say. A few of us were discussing this issue in person last week and we strongly agree with your characterization that it's very far from trivial. The consensus we came to is that the compiler should continue associating the original line number with each instruction that came from it, but perhaps should also provide additional, not-yet-defined annotations to allow the debugger to be able to provide various different types of breakpoints, corresponding to various purposes the programmer us using the breakpoints for.