From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27056 invoked by alias); 3 Jan 2003 18:03:51 -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 27042 invoked from network); 3 Jan 2003 18:03:46 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 209.249.29.67 with SMTP; 3 Jan 2003 18:03:46 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id h03I3T016468; Fri, 3 Jan 2003 12:03:29 -0600 Date: Fri, 03 Jan 2003 18:03:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200301031803.h03I3T016468@duracef.shout.net> To: ezannoni@redhat.com Subject: Re: [RFA/PATCH] breakpoint.c: fix until command Cc: drow@mvista.com, gdb-patches@sources.redhat.com, msnyder@redhat.com X-SW-Source: 2003-01/txt/msg00072.txt.bz2 Elena Z writes: > this is essentially what it does now. But instead of erroring out it > stops at the exit from the current frame. Because we cannot reliably > distinguish a. from b. Roughly, your error is equivalent to exiting > the frame. Yes. It is quite similar to the existing behavior, just with the error attached. In a way, the point of the error is to seal off an unruly possibility. That enables 'until' and 'until LOCATION' to be simple and consistent: they would always stop in either the current frame or the return-breakpoint. It's up to you to decide, I just needed to voice my proposal. I will calm down now. :) Michael C