Re: [PATCH 2/3] Add -P command line switch for executing Python scripts

[Kevin Buettner <kevinb@redhat.com>]

On Tue, 23 Jul 2019 14:25:06 -0600
Tom Tromey <tom@tromey.com> wrote:

> >>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:  
> 
> Kevin> This commit introduces a new command line switch to GDB, a -P /
> Kevin> --python switch which is used for executing a python script.
> Kevin> Encountering -P curtails normal argument processing by GDB; any
> Kevin> remaining arguments (after the script name) are passed to the
> Kevin> script.  
> 
> Kevin> 1) After script execution, exit() was called which (obviously)
> Kevin>    caused GDB to exit.
> Kevin> 2) The printing of GDB's banner (copyright info, bug reporting
> Kevin>    instructions, and help instructions) was suppressed.
> Kevin> 3) Due to the exit() noted above, GDB's CLI was not (automatically)
> Kevin>    invoked.  If the CLI was desired, it could be run from the Python
> Kevin>    script via use of the gdb.cli method, which was added as part of
> Kevin>    that work.  
> 
> Kevin> I've changed things so that exit() is no longer called.  GDB's CLI
> Kevin> will be invoked after script execution.  Also, GDB's banner will be
> Kevin> printed (or not) as normal.  I.e, the banner will be printed unless
> Kevin> the -q switch is specified.  
> 
> Kevin> If the script doesn't want the CLI for some reason, it can explicitly
> Kevin> call exit().  It may be the case that the script would be better off
> Kevin> calling a (yet to be written) gdb.exit() method for doing this
> Kevin> instead.  Such a method could make sure that GDB shuts down properly.  
> 
> The intent of -P was to provide a way to run gdb in a "Python script"
> mode.  I think this changes defeat this goal.
> 
> For (2), printing the banner is just not great for an interpreter.  The
> default for interpreters should be silence, with the script being
> interpreted choosing what to emit.  "-q" isn't sufficient because it is
> common for #! handling to only allow a single argument.
> 
> I think if -P is going to just mean "start gdb, but interpret some
> Python script at startup", then it might as well not exist -- an
> invocation like '-ex "source blah.py"' is just as good, and can be used
> on older gdbs as well.
> 
> (1) and (3) seem linked.  Here the idea was to have a way to script gdb
> where the command line was completely optional and under control of the
> script.
> 
> Maybe -P isn't the right vehicle for this.  Later on, I was looking at
> having a "Python" gdb interpreter -- not to actually interpret gdb
> input, but to at least control gdb output.  And, I looked into compiling
> gdb PIE so that one could just "import gdb" from an ordinary Python
> interpreter.

Thanks for that critique / explanation.

I'm going to mull this over some more...

Kevin