From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27678 invoked by alias); 3 Jan 2003 23:58:47 -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 27671 invoked from network); 3 Jan 2003 23:58:46 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 3 Jan 2003 23:58:46 -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 h03NVCB03860 for ; Fri, 3 Jan 2003 18:31:12 -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 h03NwWn28003; Fri, 3 Jan 2003 18:58:32 -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 h03NwWn01027; Fri, 3 Jan 2003 15:58:32 -0800 Message-ID: <3E1623A8.6BECBAB0@redhat.com> Date: Fri, 03 Jan 2003 23:58: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> <15893.39903.509751.97803@localhost.redhat.com> <3E161D25.6E714CA1@redhat.com> <15894.8935.974956.731935@localhost.redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00126.txt.bz2 Elena Zannoni wrote: > > Michael Snyder writes: > > > > > > > I don't think there is a way to have both behaviors work correctly. I > > > > > > thought of checking that the pc which you want to run until is in > > > > > > the same function as the one of the selected frame, and in that case > > > > > > enforce the check (by using a non-null frame for the bp_until), > > > > > > otherwise use the null frame (which disables the check). But what would > > > > > > be the correct behavior if you say: > > > > > > > > > > > > "until bar" where bar is recursive, and you are in "bar" at the > > > > > > moment? This doesn't work currently. It seems intuitive that you > > > > > > would stop the next time you enter "bar". Right now you end up at the > > > > > > caller of "bar". > > > > > > > > > > > I agree, but maybe we can distinguish between "a location inside the > > current function" and "a location outside the current function". > > After all, a line is not a meaningful distinction -- it could be a > > line inside another function. > > > > So I suggest using find_pc_partial_function to find the bounds > > of the current function. If is inside, we use a > > frame-relative breakpoint. If it's outside, we don't. > > > > Wouldn't that satisfy the issue that you're working on? > > See the above, in this very same thread. :-) I tried this yesterday, > but I ran into a corner case. If we decide what to do in this corner > case, we should be ok. What if we can come to a consensus regarding "until bar"?