From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17342 invoked by alias); 3 Jan 2003 14:43:59 -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 17335 invoked from network); 3 Jan 2003 14:43:59 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 3 Jan 2003 14:43:59 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h03EGSB22991 for ; Fri, 3 Jan 2003 09:16:28 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h03Ehla07879; Fri, 3 Jan 2003 09:43:47 -0500 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h03Ehim15212; Fri, 3 Jan 2003 09:43:44 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id D9308FF79; Fri, 3 Jan 2003 09:48:07 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15893.41639.744681.895393@localhost.redhat.com> Date: Fri, 03 Jan 2003 14:43:00 -0000 To: Michael Elizabeth Chastain Cc: drow@mvista.com, msnyder@redhat.com, ezannoni@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFA/PATCH] breakpoint.c: fix until command In-Reply-To: <200301030415.h034FYW05352@duracef.shout.net> References: <200301030415.h034FYW05352@duracef.shout.net> X-SW-Source: 2003-01/txt/msg00061.txt.bz2 Michael Elizabeth Chastain writes: > 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). See the thread from November on gdb@sources. > > 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'. > Which tells me that the design was flawed. > How about this: > > . require that LOCATION in 'until LOCATION' to be in the current > function and after $PC. If it's not, then error. > > . 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. > > . change the manual to reflect this > Definitely the description in the manual needs more detail. I prefer the until == tbreak behavior, which seems the most intuitive, given the replies to the November thread. I think that using decode_line_1 may be the real problem, because that allows all kind of arguments to be used, just like for a breakpoint. > 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'. > > 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. My case was when bar is recursive. you will execute the beginning of bar again, so 'until bar' would make sense in this case. I think this is what throws a wrench in the works. > > 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'. > Don't know, I don't like it, but whatever we do we need to disambiguate the behavior. It's just plain confusing right now. > >From the Peanut Gallery, > > Michael C