From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22321 invoked by alias); 3 Jan 2003 23:53:41 -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 22311 invoked from network); 3 Jan 2003 23:53:40 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 3 Jan 2003 23:53:40 -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 h03NQ7B02829 for ; Fri, 3 Jan 2003 18:26:07 -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 h03NrSa05099; Fri, 3 Jan 2003 18:53:28 -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 h03NrQl28333; Fri, 3 Jan 2003 18:53:27 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id 07A4FFF79; Fri, 3 Jan 2003 18:57:50 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15894.9086.849437.238762@localhost.redhat.com> Date: Fri, 03 Jan 2003 23:53:00 -0000 To: Michael Snyder Cc: Elena Zannoni , Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [RFA/PATCH] breakpoint.c: fix until command In-Reply-To: <3E1621FF.A822AD5C@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> <15893.40776.758960.171190@localhost.redhat.com> <3E1621FF.A822AD5C@redhat.com> X-SW-Source: 2003-01/txt/msg00125.txt.bz2 Michael Snyder writes: > Elena Zannoni wrote: > > > > Michael Snyder writes: > > > > 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. > > Agreed, with the qualification given. > > > b. line in function in inner frame --> continue until the line is reached. > > Agreed. > > > c. line in function not in inner frame --> continue until current frame pops. > > Agreed. > > > (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. > > I think this could be stated simply as "continue until the line > is reached by the current execution frame". > > > --> this is the main problem, > > because the condition is basically impossible to figure out at run > > time. > > If we can figure it out at runtime, you would agree to it? > > > until funcname: > > d. funcname called from current frame (2) --> continue until func is reached > > Agreed. > > > e. funcname not called from current frame --> cont until current frame pops. > > Agreed. > > > (2) if current function is recursive and funcame == current function > > we want to stop at the next inner invocation of funcname > > Ow, not obvious. But since it clearly isn't specified now, > I suppose we could make up such a stipulation if we choose to. > I don't even know what the traditional behavior would be in > this case. > > > > The 'continue until current frame pops' behavior is already there. It > > always puts another bp_until at the caller. > > Yep. > > So AFAICT, we have only one corner case to agree upon. > "until factorial". yes yes yes! (see my previous message).