From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29766 invoked by alias); 3 Jan 2003 21:52:27 -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 29757 invoked from network); 3 Jan 2003 21:52:27 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 3 Jan 2003 21:52:27 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h03LOqB08419 for ; Fri, 3 Jan 2003 16:24:53 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h03Lq9n25123; Fri, 3 Jan 2003 16:52:09 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h03Lq7n21475; Fri, 3 Jan 2003 13:52:07 -0800 Message-ID: <3E160607.11B380B9@redhat.com> Date: Fri, 03 Jan 2003 21:52:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: [RFA/PATCH] breakpoint.c: fix until command References: <200301030415.h034FYW05352@duracef.shout.net> <20030103045917.GA29041@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00098.txt.bz2 Daniel Jacobowitz wrote: > > 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? My thoughts have run in similar grooves. ;-) The sticking point is "is in the current function?" I believe we can answer that, by calling find_pc_partial_function. That will give us the function's address range, and we can then immediately determine whether is in (use frame-relative bp), or out (don't do that). Michael