From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16132 invoked by alias); 3 Jan 2003 16:57:19 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 16125 invoked from network); 3 Jan 2003 16:57:18 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 3 Jan 2003 16:57:18 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18UX0j-0002cn-00; Fri, 03 Jan 2003 12:57:37 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18UV89-0000J5-00; Fri, 03 Jan 2003 11:57:09 -0500 Date: Fri, 03 Jan 2003 16:57:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/PATCH] breakpoint.c: fix until command Message-ID: <20030103165709.GA1070@nevyn.them.org> Mail-Followup-To: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com References: <200301031638.h03GcP615183@duracef.shout.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301031638.h03GcP615183@duracef.shout.net> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00068.txt.bz2 On Fri, Jan 03, 2003 at 10:38:25AM -0600, Michael Elizabeth Chastain wrote: > Hi Daniel, > > mec> So we might need additional promises. > mec> I think it would be reasonable for us to ask for them if we decide > mec> we need them. > > drow> I don't. Promises don't mean anything; we have existing code. > > A promise in a manual is a contract. If gcc violates its contract, > then gcc is at fault, and we can file bug reports against it. That's > what I'm getting at. We support other compilers; we support other versions of GCC. The life of a debugger is that making people fix the compiler isn't going to fly. > mec> If we are in foo:67, and the user asks to 'until 70', > mec> then I bet we can figure out that '70' is in the current function no > mec> matter where its object code addresses are. > > drow> No, we can't. It's a pretty fundamental rule that we can never do > drow> anything except display source lines. Consider code re-organization, > drow> templates, macros, #line directives... > > Okay, I am naive here. I see a DW_TAG_subprogram for each function > with a DW_AT_decl_line. Can't we use that information to build a table > that maps source line #'s to function names? > > But you know much more about this area then I do so if you are gloomy, > I have to be gloomy, too. No. Here's the problem: generally, a code address maps to one file:line pair. Generally. It's not always clear what file:line it is, and sometimes it could reasonably map to multiple file:line's; for instance, common subexpression hoisting. But generally, we can go from PC to file:line. Right now we have code to go from file:line to PC. However, assuming that you can do that is wrong. Consider: inline int baz() { return something -complicated; } int main() { int a; a = baz(); return a * baz(); } We're on the "return something" line. For the purposes of "until", if someone said we could go to the "-complicated" line, it's obvious what we mean; this inline instance. In general, that's not true. From the linespec we have no way to figure out which inline instance is referred to. We lose. [Similarly, we need to stop assuming a symbol name maps to one PC. This causes us to mess up constructor breakpoints right now. GDB has essentially no support for debugging inline functions, and it's a problem there too. DWARF-2 tells us where every single inlined copy is, but what do we do with that information? More, how do we present it to the user? Big interface problems here.] -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer