Re: [PATCH v3 3/4] gdb/cli: add '.' as an argument for 'list' command

[Bruno Larsen <blarsen@redhat.com>]

On 21/06/2023 19:25, Keith Seitz wrote:
> On 6/21/23 03:45, Bruno Larsen via Gdb-patches wrote:
>> Currently, after the user has used the list command once, there is no
>> way to ask GDB to print the location where the inferior is stopped.
>> This commit adds a way to do that using '.' as a new argument for the
>> 'list' command.  If the inferior isn't running, the command throws an
>> error.  The test gdb.base/list.exp was updated to test this new 
>> argument.
>
> I'm not entirely sure how I feel about throwing an error when using
> "list ." with no running inferior. Can you explain why that might be
> preferable to, say, just mimicking "list" with no argument or some other
> fallback?
>
> [I'm not going to NACK this patch for this, of course. I am just normally
> cautious about adding errors when logical, convenient fallbacks could
> be used instead.]
My logic was that '.' is supposed to be 'current location', so if the 
inferior is not running, there is no current location. I'm changing it, 
no problem :)
>
> However, there is a problem that specifically needs addressing IMO.
>
> Compare (using gdb debugging gdb):
>
> (top-gdb) list 10
> 5
> 6       This program is free software; you can redistribute it and/or 
> modify
> 7       it under the terms of the GNU General Public License as 
> published by
> 8       the Free Software Foundation; either version 3 of the License, or
> 9       (at your option) any later version.
> 10
> 11       This program is distributed in the hope that it will be useful,
> 12       but WITHOUT ANY WARRANTY; without even the implied warranty of
> 13       MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> 14       GNU General Public License for more details.
> (top-gdb)
> 15
> 16       You should have received a copy of the GNU General Public 
> License
> 17       along with this program.  If not, see 
> <http://www.gnu.org/licenses/>.  */
> 18
> 19    #include "defs.h"
> 20    #include "main.h"
> 21    #include "interps.h"
> 22
> 23    int
> 24    main (int argc, char **argv)
> (top-gdb)
> 25    {
> 26      struct captured_main_args args;
> 27
> 28      memset (&args, 0, sizeof args);
> 29      args.argc = argc;
> 30      args.argv = argv;
> 31      args.interpreter_p = INTERP_CONSOLE;
> 32      return gdb_main (&args);
> 33    }
> (top-gdb)
>
>
> With (after "start"):
>
> (top-gdb) list .
> 23    int
> 24    main (int argc, char **argv)
> 25    {
> 26      struct captured_main_args args;
> 27
> 28      memset (&args, 0, sizeof args);
> 29      args.argc = argc;
> 30      args.argv = argv;
> 31      args.interpreter_p = INTERP_CONSOLE;
> 32      return gdb_main (&args);
> (top-gdb)
> 23    int
> 24    main (int argc, char **argv)
> 25    {
> 26      struct captured_main_args args;
> 27
> 28      memset (&args, 0, sizeof args);
> 29      args.argc = argc;
> 30      args.argv = argv;
> 31      args.interpreter_p = INTERP_CONSOLE;
> 32      return gdb_main (&args);
> (top-gdb)
> 23    int
> 24    main (int argc, char **argv)
> 25    {
> 26      struct captured_main_args args;
> 27
> 28      memset (&args, 0, sizeof args);
> 29      args.argc = argc;
> 30      args.argv = argv;
> 31      args.interpreter_p = INTERP_CONSOLE;
> 32      return gdb_main (&args);
> (top-gdb)
>
> I don't think this is particularly user-friendly. Is it possible to make
> the two use cases behave similarly?

Today I learned about GDB dealing with command arguments! TL;DR yes, 
I'll do that in v4

For future reference (probably for myself) if you advance the arg 
pointer when handling the command, the next command invocation is going 
to use the advanced argument pointer. When handling the number, 
list_command advances the arg, so everything after the first line is 
literally a no arg invocation.

>
> Keith
>

-- 
Cheers,
Bruno