From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21429 invoked by alias); 3 Jan 2003 23:51:46 -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 21421 invoked from network); 3 Jan 2003 23:51:44 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 3 Jan 2003 23:51:44 -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 h03NOBB02407 for ; Fri, 3 Jan 2003 18:24:11 -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 h03NpSn27794; Fri, 3 Jan 2003 18:51:28 -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 h03NpRn00352; Fri, 3 Jan 2003 15:51:27 -0800 Message-ID: <3E1621FF.A822AD5C@redhat.com> Date: Fri, 03 Jan 2003 23:51:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Elena Zannoni CC: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [RFA/PATCH] breakpoint.c: fix until command 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00124.txt.bz2 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".