From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8983 invoked by alias); 3 Jan 2003 17:40:13 -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 8967 invoked from network); 3 Jan 2003 17:40:11 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 209.249.29.67 with SMTP; 3 Jan 2003 17:40:11 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id h03HdtO16125; Fri, 3 Jan 2003 11:39:55 -0600 Date: Fri, 03 Jan 2003 17:40:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200301031739.h03HdtO16125@duracef.shout.net> To: drow@mvista.com Subject: Re: [RFA/PATCH] breakpoint.c: fix until command Cc: gdb-patches@sources.redhat.com X-SW-Source: 2003-01/txt/msg00070.txt.bz2 > 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. Yeah, I see where you are coming from. I am talking about a mapping from file:line to source function without going through PC's at all. That would not handle the case of 'until *0x12345678'. But it would handle other cases. In your example: the target program is on line 11, "return a * baz()". The user asks to proceed "until 4", which is the "-complicated" part of inline function baz(). In my design, gdb would say: "error, line 4 is not in main". I think your point is that code from line 4 actually is present in main() because baz() got inlined into main. (And in your example, line 4 is present exactly once in main, whereas in the general case it could be present multiple times). What happens right now when the user types "break 4" to break inside the inline function? I'm experimenting, and it looks like gdb sets one breakpoint on one caller to the inline function. "break 4" does not work properly. Once we have mechanism to implement "break 4", we can use the same mechanism for "until 4". We can calculate the set of locations for "break 4" and intersect that with the low_pc and high_pc of the current frame. If that set is null, then error. Then set momentary breakpoints on those locations, restricted to the current frame, plus a momentary breakpoint on the return location, and proceed. Until "break 4" works, "until 4" can at least refuse to do anything. > [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.] I agree. The constructor part is really hurting users. With inline functions, the programmer knows "I have copies of the object code for the function everywhere, I understand why gdb is not smart enough to handle that yet." With constructors, the programmer does not know that they have multiple copies of the object code, so gdb's deficiency shows up as a surprise. Michael C