From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4061 invoked by alias); 3 Jan 2003 23:09:50 -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 4054 invoked from network); 3 Jan 2003 23:09:50 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 3 Jan 2003 23:09:50 -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 h03MgGB26624 for ; Fri, 3 Jan 2003 17:42:17 -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 h03N9an26839; Fri, 3 Jan 2003 18:09:36 -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 h03N9an28865; Fri, 3 Jan 2003 15:09:36 -0800 Message-ID: <3E161830.C1584CDB@redhat.com> Date: Fri, 03 Jan 2003 23:09: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, shebs@apple.com Subject: Re: [RFA/PATCH] breakpoint.c: fix until command References: <200301030415.h034FYW05352@duracef.shout.net> <20030103045917.GA29041@nevyn.them.org> <3E160607.11B380B9@redhat.com> <20030103215435.GA32397@nevyn.them.org> <15894.4642.258968.5481@localhost.redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00114.txt.bz2 Elena Zannoni wrote: > > Daniel Jacobowitz writes: > > On Fri, Jan 03, 2003 at 01:52:07PM -0800, Michael Snyder wrote: > > > > I'm still undecided about what to do if LOCATION is not in the > > > > function. Maybe you're right and we should make this an error. What > > > > if LOCATION is in the frame that called this one? > > > > > > My thoughts have run in similar grooves. ;-) > > > The sticking point is "is in the current function?" > > > I believe we can answer that, by calling find_pc_partial_function. > > > That will give us the function's address range, and we can then > > > immediately determine whether is in (use frame-relative bp), > > > or out (don't do that). > > > > I think we're making actual progress here.... I agree. > > > > > but this is the opposite of what we agreed on a month ago. > > > We are giving up on the until foo behavior now. I thought we were trying to find a way to accomodate both behaviors. > Anyway, do an 'help until' in gdb.... the text of it goes back as > far as the frame checking code, which just shows that this whole thing > was botched from day one. Yep, the frame behavior has never been documented. Maybe we should really find out whether anyone else's recollections about this match mine... [Yo Stan...]