[PATCH 2/3] Add -P command line switch for executing Python scripts
Wed Aug 21 16:39:00 GMT 2019
On 7/23/19 9:25 PM, Tom Tromey wrote:
>>>>>> "Kevin" == Kevin Buettner <firstname.lastname@example.org> 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'm probably being dense, but I don't really understand this remark.
Can you expand on what does
"#! 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.
A selling point that I recalled about the patch when we started
discussing it internally was that you can pass arguments directly to
the script from the command line, like:
$ gdb -P blah.py py-arg1 py-arg2
I wonder if people find that feature itself useful, regardless of
the original motivation for the patch?
> (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
> 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
FYI, and FWIW, we ended up dropping this patch from Fedora GDB.
More information about the Gdb-patches