From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5857 invoked by alias); 3 Jan 2003 23:13:10 -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 5809 invoked from network); 3 Jan 2003 23:13:09 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 3 Jan 2003 23:13:09 -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 h03MjaB27436 for ; Fri, 3 Jan 2003 17:45:36 -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 h03NCun26925; Fri, 3 Jan 2003 18:12:56 -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 h03NCtn29271; Fri, 3 Jan 2003 15:12:55 -0800 Message-ID: <3E1618F7.601A1127@redhat.com> Date: Fri, 03 Jan 2003 23:13:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Elena Zannoni CC: Michael Elizabeth Chastain , drow@mvista.com, gdb-patches@sources.redhat.com Subject: Re: [RFA/PATCH] breakpoint.c: fix until command References: <200301030415.h034FYW05352@duracef.shout.net> <15893.41639.744681.895393@localhost.redhat.com> <3E16096D.9123799D@redhat.com> <15894.4882.468536.407063@localhost.redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00115.txt.bz2 Elena Zannoni wrote: > > Michael Snyder writes: > > Elena Zannoni wrote: > > > > > > 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. > > > > 'Design'? ;-) > > > > > > > > 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. > > > > Well, but that's the stated intent. Maybe it was over-ambitious? > > > > very likely so. If you accept the arguments that 'break' accepts, then > 'until foo' should do something meaningful. Otherwise, why go through > the effort. Apparently they thought it did something useful. I tried > to build 4.16 but I cannot find a host where it builds. Maybe it > really worked both ways back then? I confess that it never occurred to me to say "until foo". > > > > 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. > > > > What happens if you're at line 100 and you say "until 99"? > > > > Well, you could be at the last line in the body of a loop, and you may > want to go to the first line of the body of the loop, for instance. So > you cannot discharge that. The question I meant to ask was "what does it currently/traditionally do?", but if you're thinking of "what _should_ it do", that's a good question too. > > > > 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. > > > > That it is, but forbidding usage that was formerly allowed > > is just another way of changing the documented (or in this > > case, un-documented) behavior. > > Well, the recursive behavior is the one that is undocumented. Look at > the output of 'help until'. I think somebody was sniffing something > powerful that day. I know, I know... It could be me, since so far I seem to be the only one who remembers it that way... but damned if I don't seem to remember reading about it in a comment -- probably in breakpoint.c.