From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25552 invoked by alias); 3 Jan 2003 04:59:22 -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 25544 invoked from network); 3 Jan 2003 04:59:21 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 3 Jan 2003 04:59:21 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18ULo0-0001Y3-00 for ; Fri, 03 Jan 2003 00:59:45 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18UJvR-00008U-00 for ; Thu, 02 Jan 2003 23:59:17 -0500 Date: Fri, 03 Jan 2003 04:59:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFA/PATCH] breakpoint.c: fix until command Message-ID: <20030103045917.GA29041@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <200301030415.h034FYW05352@duracef.shout.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301030415.h034FYW05352@duracef.shout.net> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00052.txt.bz2 On Thu, Jan 02, 2003 at 10:15:34PM -0600, Michael Elizabeth Chastain wrote: > I think the problem is inherent in the design. 'until' with no argument > is meant for getting past loops in the current stack frame. (The manual > says that). So it makes sense that it skips over all subroutine calls > and also stops if the current stack frame inadvertently exits before > getting past the end of a loop. > > 'until LOCATION' is quite different. The manual says: > > `until LOCATION' > `u LOCATION' > Continue running your program until either the specified location > is reached, or the current stack frame returns. LOCATION is any of > the forms of argument acceptable to `break' (*note Setting > breakpoints: Set Breaks). This form of the command uses > breakpoints, and hence is quicker than `until' without an argument. > > Read this way, it looks like 'until LOCATION' is mostly a synonym for > 'tbreak LOCATION; continue', with one extra tbreak at the return address > in the superior frame. (break.exp says as much but they forgot about > the case where the current stack frame returns). > > I think this is bad. We already have 'tbreak'. I think it's weird and > redundant to have another 'until LOCATION' which is a lot like 'tbreak' > and not much like 'until'. > > Also I trust Michael Snyder's interpretation of the original intent more > than this particular section of The Fine Manual. It's bad when the manual > talks about the implementation of both 'until' and 'until LOCATION' and > points out that they are different. It implies that the original designers > knew they had some inconsistency between 'until' and 'until LOCATION'. > > How about this: > > . require that LOCATION in 'until LOCATION' to be in the current > function and after $PC. If it's not, then error. With a modern compiler, "after $PC" is pretty much meaningless. Not going to fly. It could be re-ordered; there can be out-of-line code in separate sections. > . use the same steppy implementation for 'until LOCATION' as 'until', > not a breakpointy implementation. In fact, 'until' with no arguments > simply becomes 'until LOCATION' where gdb picks a location by default. I like the idea of making "until LOCATION" work like "until". I'd not been exposed to this little beauty until this conversation made me go examine the manual. I don't see any reason for that to go to a single-steppy behavior however. And what it means when LOCATION is not in function is not clear. The problem is, do we know well enough when LOCATION is or is not in FUNCTION to make any statements? I'm not kidding about the out-of-line code thing. I don't know if we care about that, though; we ignore it everywhere else. I don't want to start making "after $PC" assumptions though. > . change the manual to reflect this > > Specifically, in Elena's case of the factorial: if the user wants to > stop at line 99 in ANY frame, they can use 'tbreak 99' or 'break 99'. > If the user wants to stop at line 99 in the CURRENT frame, they can use > 'until 99'. After this discussion, I think I agree with the part of the behavior you describe above. > And in Elena's second case: what if you are in 'bar' at the moment and you > say 'until bar'? I think that should be an error, because 'bar' is in > the current function, but it is not after $PC. > > Similarly if you are currently in 'bar' and say 'until quux'. Just error it. > Don't turn it into a tbreak. > > This would make both forms of 'until' behave the same, all the time. > The user can still do whatever they want. Want to progress a little in > the same frame? Call 'until', with or without an argument. Want to be > somewhere and not care if the frames change? Call 'break' or 'tbreak'. The implicit breakpoint at the return is still somewhat useful, IMHO. It's not quite the same; when you hit one of the breakpoints (or stop for some other reason), both vanish. I don't think that's what tbreaks do. I'm still undecided about what to do if LOCATION is not in the function. Maybe you're right and we should make this an error. What if LOCATION is in the frame that called this one? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer