From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-11085-listarch-gdb-patches=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 12048 invoked by alias); 5 Dec 2001 22:06:57 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 10948 invoked from network); 5 Dec 2001 22:05:38 -0000
Received: from unknown (HELO gash2.peakpeak.com) (207.174.178.17)
  by sources.redhat.com with SMTP; 5 Dec 2001 22:05:38 -0000
Received: from creche.cygnus.com (ta0197.peakpeak.com [204.144.244.197] (may be forged))
	by gash2.peakpeak.com (8.9.3/8.9.3) with ESMTP id PAA12749;
	Wed, 5 Dec 2001 15:05:33 -0700
Received: (from tromey@localhost)
	by creche.cygnus.com (8.9.3/8.9.3) id PAA02556;
	Wed, 5 Dec 2001 15:09:37 -0700
To: Klee Dienes <klee@apple.com>
Cc: Daniel Jacobowitz <drow@mvista.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFC] add 'save-breakpoints' command
References: <E16BKC5-0002Wf-00@localhost> <20011204132721.A11047@nevyn.them.org> <E16BKXp-0002Xy-00@localhost>
X-Zippy:  ...It's REAL ROUND..  And it's got a POINTY PART right in the MIDDLE!!
 The shape is SMOOTH..  ..And COLD.. It feels very COMFORTABLE on my
 CHEEK..  I'm getting EMOTIONAL..
X-Attribution:  Tom
Reply-To: tromey@redhat.com
From: Tom Tromey <tromey@redhat.com>
Date: Wed, 05 Dec 2001 14:06:00 -0000
In-Reply-To: Klee Dienes's message of "Tue, 04 Dec 2001 13:43:53 -0500"
Message-ID: <87d71t8gke.fsf@creche.redhat.com>
X-Mailer: Gnus v5.7/Emacs 20.5
X-SW-Source: 2001-12/txt/msg00152.txt.bz2

>>>>> "Klee" == Klee Dienes <klee@apple.com> writes:

Klee> The 'future-break' command allows one to specify a breakpoint
Klee> that starts off as 'shlib_disabled' instead of generating an
Klee> error if it can't be set immediately.

Klee> I'm not entirely happy with the future-break command, and
Klee> particularly with its interaction with the save-breakpoints
Klee> mechanism (if you set a breakpoint that is in a shared library
Klee> after shared libraries have been loaded, you have to remember to
Klee> use the future-break command, not the break command).

Doesn't this mean that programs like Insight would be best advised to
*only* set future breakpoints?  In that case let's just add the
functionality directly to the existing breakpoint commands.

Tom