From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21117 invoked by alias); 3 Aug 2003 06:02:08 -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 21110 invoked from network); 3 Aug 2003 06:02:07 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 3 Aug 2003 06:02:07 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.20) id 19jB5q-0007J1-Qj; Sun, 03 Aug 2003 01:07:43 -0400 Date: Sun, 03 Aug 2003 06:02:00 -0000 Message-Id: From: Eli Zaretskii To: Andrew Cagney CC: gdb-patches@sources.redhat.com In-reply-to: <3F2C4642.4010409@redhat.com> (message from Andrew Cagney on Sat, 02 Aug 2003 19:16:18 -0400) Subject: Re: [patch/rfc, rfa:doco, 6.0] "set backtrace past-main|limit" Reply-to: Eli Zaretskii References: <3F2C4642.4010409@redhat.com> X-SW-Source: 2003-08/txt/msg00023.txt.bz2 > Date: Sat, 02 Aug 2003 19:16:18 -0400 > From: Andrew Cagney > > This patch replaces the commands: > > set/show backtrace-below-main > show backtrace-below-main > > with the pair of commands: > > set/show backtrace past-main > set/show backtrace limit I'm not sure I like what happens when the backtrace is deeper than the limit: > + if (this_frame->level > backtrace_limit) > + { > + error ("Backtrace limit of %d exceeded", backtrace_limit); > + } > + Why should this be anything as scary as `error'? Isn't a simple notice (not even a `warning') enough? > where the latter sets an absolute bound on the number of backtraces. > 10000 (arbitrary) by default. The 10000 default limit is not backward-compatible. Why not just leave it at zero, as that's how GDB behaves today? If we do set the limit by default to some number, that number should at least be documented in the manual. > eli, the doco ok? Yes, but... > +If you need to examine the startup code, or limit the number of levels > +in a backtrace, you can change this behavior: > > @table @code > -@item set backtrace-below-main off > +@item set backtrace past-main off > Backtraces will stop when they encounter the user entry point. This is the > default. I think it's better to put "@itemx set backtrace past-main on" first, and "@item set backtrace past-main off" second, because otherwise the above fragment of text doesn't make sense: you tell the reader that the default behavior can be changed, but then show them the command that sets the default behavior. > +@item set backtrace limit @var{number} > +@itemx set backtrace limit 0 > +Limit the the backtrace to @var{number} levels. A value of zero means > +unlimited. I suggest a "@cindex backtrace limit" here. That way, someone who types "backtrace" in an Info reader and then hits TAB, will see this item in the list of possible completions. Also, isn't it better to use "n" instead of "number" here? It seems to me that Limit the backtrace to N levels sounds better in English than Limit the backtrace to NUMBER levels Do you agree? Finally, note the two consecutive "the" before "backtrace"; a typo. Otherwise, this docs change is okay; thanks.