From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17158 invoked by alias); 11 Dec 2001 11:55:09 -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 17131 invoked from network); 11 Dec 2001 11:55:05 -0000 Received: from unknown (HELO is.elta.co.il) (199.203.121.2) by sources.redhat.com with SMTP; 11 Dec 2001 11:55:05 -0000 Received: from is (is [199.203.121.2]) by is.elta.co.il (8.9.3/8.8.8) with SMTP id NAA02385; Tue, 11 Dec 2001 13:54:22 +0200 (IST) Date: Tue, 11 Dec 2001 03:55:00 -0000 From: Eli Zaretskii X-Sender: eliz@is To: Klee Dienes cc: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFC] add 'save-breakpoints' command In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001-12/txt/msg00298.txt.bz2 On Tue, 11 Dec 2001, Klee Dienes wrote: > In addition to the 'save-breakpoints' support already submitted, this > patch adds a new command 'future-break', that works like break except > that when it encounters an error, instead of returning to top-level, Thanks. Can we perhaps come up with a better name instead of `future-break'? It doesn't really describe well enough what does this command do, IMHO. For example, if it is possible to put a breakpoint at the time the user issues the command, GDB will do that without delays, so the word ``future'' is inaccurate. A related question is: maybe we should make all breakpoint commands behave like this by default? > * doc/gdb.textinfo: Add documentation for 'save-breakpoints' and > 'future-break'. The changes to the docs are approved, with a few minor comments (see below). > * main.c (captured_main): Initialize $input_radix and $output_radix. > These are referenced by a save-breakpoints file to preserve radix > across the breakpoint restoration. This aspect of save-breakpoints isn't mentioned in the gdb.texinfo patch. Please add it; I think it's important to say that in the manual, since the radix has effect on features other than breakpoints. > +@kindex future-break > +@item future-break @var{args} > +Set a `future' breakpoint. @var{args} are the same as for the ^^^^^^^^ This should be either ``future'' or @emph{future}, probably the former. > +@code{hbreak} command and the breakpoint is set in the same way. Is it really like hbreak or like break? That is, does GDB set a hardware-assisted breakpoint? If so, what happens on platforms which don't support hbreak? Also, I'd suggest to add a sentence or two about the situations where this command could be useful. > +@item save-breakpoints > +Save all current breakpoint definitions, together with their > +ignore-counts and command scripts, into the file @file{@var{filename}}. If the command accepts an argument, the file name, the @item above should say this: @item save-breakpoints @var{filename}