From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14310 invoked by alias); 3 Jan 2003 14:29:35 -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 14303 invoked from network); 3 Jan 2003 14:29:33 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 3 Jan 2003 14:29:33 -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 h03E23B20516 for ; Fri, 3 Jan 2003 09:02:03 -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 h03ETMa04751; Fri, 3 Jan 2003 09:29:22 -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 h03ETKm14282; Fri, 3 Jan 2003 09:29:20 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id E06AEFF79; Fri, 3 Jan 2003 09:33:44 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15893.40776.758960.171190@localhost.redhat.com> Date: Fri, 03 Jan 2003 14:29:00 -0000 To: Michael Snyder Cc: Daniel Jacobowitz , ezannoni@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFA/PATCH] breakpoint.c: fix until command In-Reply-To: <3E14F768.DA13CB07@redhat.com> References: <15875.24035.153991.390184@localhost.redhat.com> <3E07A1F2.E7B77C89@redhat.com> <20021224000211.GA8155@nevyn.them.org> <3E07B0DC.CC733B10@redhat.com> <20021224010306.GA10409@nevyn.them.org> <3E14A019.4A600913@redhat.com> <15892.41806.882466.952438@localhost.redhat.com> <15892.54871.381942.260248@localhost.redhat.com> <3E14EB0A.15D7724E@redhat.com> <20030103015102.GA8209@nevyn.them.org> <3E14F768.DA13CB07@redhat.com> X-SW-Source: 2003-01/txt/msg00060.txt.bz2 Michael Snyder writes: > > > You raise a good point. The commands "until " and "until " > > > are inconsistant. Moreover the docs do not seem to describe this > > > recursion behavior. Maybe a conversation with a wider audience is > > > in order (the gdb list)? I'm sure I can't be the only one who > > > remembers that "until" behaved this way, and we shouldn't change > > > the behavior precipitously. > > > > Am I the only one getting the feeling that we have two useful behaviors > > here; and that we should pick one for "until" but expose the other > > under some other name or with some option? > > ;-) That's often the case when someone feels 'intuitively' that > gdb should behave differently. We have to look out for feeping > creaturitis, but in this case I'm getting the impression that the > two behaviors are mutually incompatible, and may need to be separated > somehow. > > If you say "until ", and the line is inside the current function, > you can impose the frame restriction. If the line (or address) is outside > the current function, or if you give a function name or something else, > you can't. And I don't think we can code that distinction at runtime. I think we should come up with a behavior matrix, something like: until: continue until next source line is reached. If already at the last line of current function, continue until current frame pops. until line: a. line in current function (1) --> continue until the line is reached. b. line in function in inner frame --> continue until the line is reached. c. line in function not in inner frame --> continue until current frame pops. (1) However if current function is recursive, a. should become like b. But we want to enforce a different behavior, because we don't want to stop in the inner frame. --> this is the main problem, because the condition is basically impossible to figure out at run time. until funcname: d. funcname called from current frame (2) --> continue until func is reached e. funcname not called from current frame --> cont until current frame pops. (2) if current function is recursive and funcame == current function we want to stop at the next inner invocation of funcname The 'continue until current frame pops' behavior is already there. It always puts another bp_until at the caller.