From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29775 invoked by alias); 4 Jan 2003 00:05:26 -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); 4 Jan 2003 00:05:25 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 4 Jan 2003 00:05:25 -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 h03NbqB04979 for ; Fri, 3 Jan 2003 18:37:52 -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 h0405Cn28158; Fri, 3 Jan 2003 19:05:12 -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 h0405Bn01575; Fri, 3 Jan 2003 16:05:11 -0800 Message-ID: <3E162537.63F529DF@redhat.com> Date: Sat, 04 Jan 2003 00:05: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> <3E1621FF.A822AD5C@redhat.com> <15894.9086.849437.238762@localhost.redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00127.txt.bz2 Elena Zannoni wrote: > > 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! Well then... 1) Use find_pc_partial_function to determine bounds and distinguish between in-bounds and out-of-bounds locations. 2) For func_start > loc >= func_end, use a frame-relative bp. 3) For func_start == loc or loc < func_start or loc > func_end, use a frameless bp. 4) document, document, document! Including the recursive corner case. Agreed, Elena? Daniel? Michael? Anyone else?