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

[Tom Tromey <tom@tromey.com>]

>>>>> "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,
Tom