This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 7/23/19 9:25 PM, Tom Tromey 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'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."
mean?

> 
> 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
> 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.

FYI, and FWIW, we ended up dropping this patch from Fedora GDB.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]