This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 2/3] Add -P command line switch for executing Python scripts
On Tue, 23 Jul 2019 14:25:06 -0600
Tom Tromey <firstname.lastname@example.org> wrote:
> >>>>> "Kevin" == Kevin Buettner <email@example.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
> 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
Thanks for that critique / explanation.
I'm going to mull this over some more...