This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA v3 01/13] Rationalize "backtrace" command line parsing


> From: Tom Tromey <tom@tromey.com>
> Cc: Tom Tromey <tom@tromey.com>
> Date: Fri, 23 Mar 2018 14:55:00 -0600
> 
> The backtrace command has peculiar command-line parsing.  In
> particular, it splits the command line, then loops over the arguments.
> If it sees a word it recognizes, like "full", it effectively drops
> this word from the argument vector.  Then, it pastes together the
> remaining arguments, passing them on to backtrace_command_1, which in
> turn passes the resulting string to parse_and_eval_long.
> 
> The documentation doesn't mention the parse_and_eval_long at all, so
> it is a bit of a hidden feature that you can "bt 3*2".  The strange
> algorithm above also means you can "bt 3 * no-filters 2" and get 6
> frames...
> 
> This patch changes backtrace's command line parsing to be a bit more
> rational.  Now, special words like "full" are only recognized at the
> start of the command.
> 
> This also updates the documentation to describe the various bt options
> individually.
> 
> gdb/ChangeLog
> 2018-03-23  Tom Tromey  <tom@tromey.com>
> 
> 	* stack.c (backtrace_command): Rewrite command line parsing.
> 
> gdb/doc/ChangeLog
> 2018-03-23  Tom Tromey  <tom@tromey.com>
> 
> 	* gdb.texinfo (Backtrace): Describe options individually.
> ---
>  gdb/ChangeLog       |  4 ++++
>  gdb/doc/ChangeLog   |  4 ++++
>  gdb/doc/gdb.texinfo | 54 ++++++++++++++++++++--------------------------
>  gdb/stack.c         | 62 +++++++++++++++++------------------------------------
>  4 files changed, 51 insertions(+), 73 deletions(-)
> 
> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
> index 74e0fdb4a4..b48dd4ed4b 100644
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -7307,39 +7307,31 @@ frame (frame zero), followed by its caller (frame one), and on up the
>  stack.
>  
>  @anchor{backtrace-command}
> -@table @code
>  @kindex backtrace
>  @kindex bt @r{(@code{backtrace})}
> -@item backtrace
> -@itemx bt
> -Print a backtrace of the entire stack: one line per frame for all
> -frames in the stack.
> -
> -You can stop the backtrace at any time by typing the system interrupt
> -character, normally @kbd{Ctrl-c}.
> -
> -@item backtrace @var{n}
> -@itemx bt @var{n}
> -Similar, but print only the innermost @var{n} frames.
> -
> -@item backtrace -@var{n}
> -@itemx bt -@var{n}
> -Similar, but print only the outermost @var{n} frames.
> -
> -@item backtrace full
> -@itemx bt full
> -@itemx bt full @var{n}
> -@itemx bt full -@var{n}
> -Print the values of the local variables also.  As described above,
> -@var{n} specifies the number of frames to print.
> -
> -@item backtrace no-filters
> -@itemx bt no-filters
> -@itemx bt no-filters @var{n}
> -@itemx bt no-filters -@var{n}
> -@itemx bt no-filters full
> -@itemx bt no-filters full @var{n}
> -@itemx bt no-filters full -@var{n}

Is it wise to delete the @table?  We always describe commands in that
format, AFAIR.

> +Print a backtrace of the entire stack, use the @code{backtrace}
> +command, or its alias @code{bt}.  This command will print one line per

I gues you meant "To print a backtrace of the entire stack ...",
because otherwise the first sentence reads weirdly.

Otherwise, the documentation part is OK.  Thanks.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]