RFC: add ability to "source" Python code

RFC: add ability to "source" Python code

[Tom Tromey]

This patch adds Python support to the gdb "source" command.
I added this after several user questions about how to do this.
Also, due to completion, it is much more convenient than the
equivalent "python" command.

With this patch, a file ending in ".py" is automatically treated as
Python.  Also, other files can be interpreted as Python code by using
the "-p" switch.  I made other switches into errors, on the theory
that maybe we'd want to take more later ... I'm not sure if this is a
good idea or not.

This patch also changes '-x' to accept .py files, as a side effect.

This could use a documentation review.  Also I'd appreciate any
comments on it; it does change "source" incompatibly, though in a way
that is very unlikely to affect users.

Built and regression tested on x86-64 (compile farm).
New test case included.

Tom

2009-02-07  Tom Tromey  <tromey@redhat.com>

	* python/python.c (source_python_script): New function.
	* python/python.h (source_python_script): Declare.
	* cli/cli-cmds.c (find_argument): New function.
	(source_command): Use find_argument.  Handle -p argument.  Use
	make_cleanup_restore_integer.
	(source_verbose_cleanup): Remove.
	(source_python): New global.
	Include python.h.
	(init_cli_cmds): Update.

2009-02-07  Tom Tromey  <tromey@redhat.com>

	* gdb.texinfo (File Options): Document -x on .py files.
	(Command Files): Document source -p.

2009-02-07  Tom Tromey  <tromey@redhat.com>

	* gdb.base/help.exp: Update "source" help text.
	* gdb.python/source2.py: New file.
	* gdb.python/source1: New file.
	* gdb.python/python.exp: Test "source" command.

diff --git a/gdb/cli/cli-cmds.c b/gdb/cli/cli-cmds.c
index 4d9c4f3..3713927 100644
--- a/gdb/cli/cli-cmds.c
+++ b/gdb/cli/cli-cmds.c
@@ -45,6 +45,8 @@
 #include "cli/cli-setshow.h"
 #include "cli/cli-cmds.h"
 
+#include "python/python.h"
+
 #ifdef TUI
 #include "tui/tui.h"		/* For tui_active et.al.   */
 #endif
@@ -178,6 +180,7 @@ struct cmd_list_element *showchecklist;
 
 /* Command tracing state.  */
 
+static int source_python = 0;
 int source_verbose = 0;
 int trace_commands = 0;
 \f
@@ -439,6 +442,7 @@ source_script (char *file, int from_tty)
   struct cleanup *old_cleanups;
   char *full_pathname = NULL;
   int fd;
+  int is_python;
 
   if (file == NULL || *file == 0)
     {
@@ -471,30 +475,44 @@ source_script (char *file, int from_tty)
 	}
     }
 
+  is_python = source_python;
+  if (strlen (file) > 3 && !strcmp (&file[strlen (file) - 3], ".py"))
+    is_python = 1;
+
   stream = fdopen (fd, FOPEN_RT);
-  script_from_file (stream, file);
+
+  if (is_python)
+    source_python_script (stream, file);
+  else
+    script_from_file (stream, file);
 
   do_cleanups (old_cleanups);
 }
 
-/* Return the source_verbose global variable to its previous state
-   on exit from the source command, by whatever means.  */
-static void
-source_verbose_cleanup (void *old_value)
+/* A helper for source_command.  Look for an argument in *ARGS.
+   Update *ARGS by stripping leading whitespace.  If an argument is
+   found, return it (a character).  Otherwise, return 0.  */
+static int
+find_argument (char **args)
 {
-  source_verbose = *(int *)old_value;
-  xfree (old_value);
+  int result = 0;
+  while (isspace ((*args)[0]))
+    ++*args;
+  if ((*args)[0] == '-' && isalpha ((*args)[1]))
+    {
+      result = (*args)[1];
+      *args += 3;
+    }
+  return result;
 }
 
 static void
 source_command (char *args, int from_tty)
 {
   struct cleanup *old_cleanups;
-  char *file = args;
-  int *old_source_verbose = xmalloc (sizeof(int));
 
-  *old_source_verbose = source_verbose;
-  old_cleanups = make_cleanup (source_verbose_cleanup, old_source_verbose);
+  old_cleanups = make_cleanup_restore_integer (&source_verbose);
+  make_cleanup_restore_integer (&source_python);
 
   /* -v causes the source command to run in verbose mode.
      We still have to be able to handle filenames with spaces in a
@@ -502,23 +520,28 @@ source_command (char *args, int from_tty)
 
   if (args)
     {
-      /* Make sure leading white space does not break the comparisons.  */
-      while (isspace(args[0]))
-	args++;
-
-      /* Is -v the first thing in the string?  */
-      if (args[0] == '-' && args[1] == 'v' && isspace (args[2]))
+      while (1)
 	{
-	  source_verbose = 1;
-
-	  /* Trim -v and whitespace from the filename.  */
-	  file = &args[3];
-	  while (isspace (file[0]))
-	    file++;
+	  int arg = find_argument (&args);
+	  if (!arg)
+	    break;
+	  switch (arg)
+	    {
+	    case 'v':
+	      source_verbose = 1;
+	      break;
+	    case 'p':
+	      source_python = 1;
+	      break;
+	    default:
+	      error (_("unrecognized option -%c"), arg);
+	    }
 	}
     }
 
-  source_script (file, from_tty);
+  source_script (args, from_tty);
+
+  do_cleanups (old_cleanups);
 }
 
 
@@ -1281,6 +1304,8 @@ Commands defined in this way may have up to ten arguments."));
 Read commands from a file named FILE.\n\
 Optional -v switch (before the filename) causes each command in\n\
 FILE to be echoed as it is executed.\n\
+Optional -p switch (before the filename) causes FILE to be evaluated\n\
+as Python code.\n\
 Note that the file \"%s\" is read automatically in this way\n\
 when GDB is started."), gdbinit);
   c = add_cmd ("source", class_support, source_command,
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 166b84d..e6472ae 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -955,8 +955,10 @@ Connect to process ID @var{number}, as with the @code{attach} command.
 @itemx -x @var{file}
 @cindex @code{--command}
 @cindex @code{-x}
-Execute @value{GDBN} commands from file @var{file}.  @xref{Command
-Files,, Command files}.
+Execute commands from file @var{file}.  If @var{file} ends in
+@samp{.py}, then the file is evaluated as Python code.  If Python
+support is not enabled in this @value{GDBN}, then an error occurs.
+@xref{Command Files,, Command files}.
 
 @item -eval-command @var{command}
 @itemx -ex @var{command}
@@ -17753,7 +17755,7 @@ command:
 @table @code
 @kindex source
 @cindex execute commands from a file
-@item source [@code{-v}] @var{filename}
+@item source [@code{-v}] [@code{-p}] @var{filename}
 Execute the command file @var{filename}.
 @end table
 
@@ -17770,6 +17772,11 @@ If @code{-v}, for verbose mode, is given then @value{GDBN} displays
 each command as it is executed.  The option must be given before
 @var{filename}, and is interpreted as part of the filename anywhere else.
 
+If @var{filename} ends in @samp{.py}, or if @code{-p} (for ``Python'')
+is given, then @value{GDBN} evaluates the contents of the file as
+Python code.  If Python support is not compiled in to @value{GDBN},
+then an error occurs.
+
 Commands that would ask for confirmation if used interactively proceed
 without asking when used in a command file.  Many @value{GDBN} commands that
 normally print messages to say what they are doing omit the messages
diff --git a/gdb/python/python.c b/gdb/python/python.c
index e778ac4..b275437 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -273,6 +273,22 @@ execute_gdb_command (PyObject *self, PyObject *args)
   Py_RETURN_NONE;
 }
 
+/* Read a file as Python code.  STREAM is the input file; FILE is the
+   name of the file.  */
+
+void
+source_python_script (FILE *stream, char *file)
+{
+  PyGILState_STATE state;
+
+  state = PyGILState_Ensure ();
+
+  PyRun_SimpleFile (stream, file);
+
+  fclose (stream);
+  PyGILState_Release (state);
+}
+
 \f
 
 /* Printing.  */
@@ -335,6 +351,13 @@ eval_python_from_control_command (struct command_line *cmd)
   error (_("Python scripting is not supported in this copy of GDB."));
 }
 
+void
+source_python_script (FILE *stream)
+{
+  fclose (stream);
+  error (_("Python scripting is not supported in this copy of GDB."));
+}
+
 #endif /* HAVE_PYTHON */
 
 \f
diff --git a/gdb/python/python.h b/gdb/python/python.h
index e63c447..5a6a067 100644
--- a/gdb/python/python.h
+++ b/gdb/python/python.h
@@ -26,4 +26,6 @@ extern struct value *values_in_python;
 
 void eval_python_from_control_command (struct command_line *);
 
+void source_python_script (FILE *stream, char *file);
+
 #endif /* GDB_PYTHON_H */
diff --git a/gdb/testsuite/gdb.base/help.exp b/gdb/testsuite/gdb.base/help.exp
index 4618a2c..ff2838a 100644
--- a/gdb/testsuite/gdb.base/help.exp
+++ b/gdb/testsuite/gdb.base/help.exp
@@ -603,7 +603,7 @@ gdb_test "help stepi" "Step one instruction exactly\.\[\r\n\]+Argument N means d
 gdb_test "help signal" "Continue program giving it signal.*" "help signal"
 # test help source
 # vxgdb reads .vxgdbinit
-gdb_test "help source" "Read commands from a file named FILE\.\[\r\n\]+Optional -v switch \\(before the filename\\) causes each command in\[\r\n\]+FILE to be echoed as it is executed\.\[\r\n\]+Note that the file \"\[^\"\]*\" is read automatically in this way\[\r\n\]+when GDB is started\." "help source"
+gdb_test "help source" "Read commands from a file named FILE\.\[\r\n\]+Optional -v switch \\(before the filename\\) causes each command in\[\r\n\]+FILE to be echoed as it is executed\.\[\r\n\]+Optional -p switch \\(before the filename\\) causes FILE to be evaluated\[\r\n\]+as Python code\\.\[\r\n\]+Note that the file \"\[^\"\]*\" is read automatically in this way\[\r\n\]+when GDB is started\." "help source"
 # test help stack
 test_class_help "stack" {
     "Examining the stack\..*\[\r\n\]+"
diff --git a/gdb/testsuite/gdb.python/python.exp b/gdb/testsuite/gdb.python/python.exp
index a0c9b39..51c1a24 100644
--- a/gdb/testsuite/gdb.python/python.exp
+++ b/gdb/testsuite/gdb.python/python.exp
@@ -71,3 +71,6 @@ gdb_py_test_multiple "indented multi-line python command" \
   "  print 'hello, world!'" "" \
   "foo ()" "" \
   "end" "hello, world!"
+
+gdb_test "source -p $srcdir/$subdir/source1" "yes"
+gdb_test "source $srcdir/$subdir/source2.py" "yes"
diff --git a/gdb/testsuite/gdb.python/source1 b/gdb/testsuite/gdb.python/source1
new file mode 100644
index 0000000..b7ca419
--- /dev/null
+++ b/gdb/testsuite/gdb.python/source1
@@ -0,0 +1,19 @@
+#  This testcase is part of GDB, the GNU debugger.
+
+#  Copyright 2008, 2009 Free Software Foundation, Inc.
+
+#  This program is free software; you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 3 of the License, or
+#  (at your option) any later version.
+
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#  GNU General Public License for more details.
+
+#  You should have received a copy of the GNU General Public License
+#  along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# This is sourced as python; pick an expression that is not valid for gdb.
+print 'y%ss' % 'e'
diff --git a/gdb/testsuite/gdb.python/source2.py b/gdb/testsuite/gdb.python/source2.py
new file mode 100644
index 0000000..3d12222
--- /dev/null
+++ b/gdb/testsuite/gdb.python/source2.py
@@ -0,0 +1,18 @@
+#  This testcase is part of GDB, the GNU debugger.
+
+#  Copyright 2008, 2009 Free Software Foundation, Inc.
+
+#  This program is free software; you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 3 of the License, or
+#  (at your option) any later version.
+
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#  GNU General Public License for more details.
+
+#  You should have received a copy of the GNU General Public License
+#  along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+print 'y%ss' % 'e'

Re: RFC: add ability to "source" Python code

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <elpa@tromey.com> writes:

Tom> This patch adds Python support to the gdb "source" command.
Tom> I added this after several user questions about how to do this.
Tom> Also, due to completion, it is much more convenient than the
Tom> equivalent "python" command.

Whoops, sent this from the wrong account.  My multi-tasking skills
aren't what they used to be.  If you can remember, and it isn't too
much trouble, please CC my redhat.com account, not ELPA, on replies.

Thanks,
Tom

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> From: Tom Tromey <elpa@tromey.com>
> Date: Sat, 07 Feb 2009 18:16:10 -0700
> 
> This patch adds Python support to the gdb "source" command.
> I added this after several user questions about how to do this.
> Also, due to completion, it is much more convenient than the
> equivalent "python" command.

Thanks.

> This could use a documentation review.

The documentation part is okay, except that I'd add a @cindex entry
there about sourcing Python code files.

However, I don't think I like the idea of GDB barfing if Python
support is not compiled in.  I think it should simply try to interpret
the file as GDB scripting commands.

I also think we need a NEWS entry for this feature.

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Date: Sat, 07 Feb 2009 18:34:38 -0700
> 
> Whoops, sent this from the wrong account.  My multi-tasking skills
> aren't what they used to be.  If you can remember, and it isn't too
> much trouble, please CC my redhat.com account, not ELPA, on replies.

Done, albeit in a separate message.

Re: RFC: add ability to "source" Python code

[Doug Evans]

On Sat, Feb 7, 2009 at 5:16 PM, Tom Tromey <elpa@tromey.com> wrote:
> With this patch, a file ending in ".py" is automatically treated as
> Python.  Also, other files can be interpreted as Python code by using
> the "-p" switch.  I made other switches into errors, on the theory
> that maybe we'd want to take more later ... I'm not sure if this is a
> good idea or not.

It's easier to relax restrictions than it is to impose them after the fact.

IOW, I think it's a good idea.

Re: RFC: add ability to "source" Python code

[Doug Evans]

On Sat, Feb 7, 2009 at 8:08 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> However, I don't think I like the idea of GDB barfing if Python
> support is not compiled in.  I think it should simply try to interpret
> the file as GDB scripting commands.

I 3/4 disagree.  :-)

In the case of "source -p foo", I disagree.  This is new functionality
(*1), and silently (or otherwise) interpreting "source -p foo" as gdb
scripts will lead to subsequent breakage if/when python support does
get compiled in.  [That's 1/2 of the 3/4.]

In the case of "source foo.py" I sort of disagree (that's the other 1/4, fwiw).
Technically speaking it's possible that some bloke out there has a
foo.py script that actually is gdb commands, and forcing the script to
be interpreted as python would break that.  It's seems really unlikely
though.

Perhaps "source" could/should also take a -g option to force the
script to be interpreted as gdb commands.  It mightn't be sufficient
to justify breaking an existing "source foo.py" being interpreted as
gdb commands (though I think it is), but it might be reasonable to add
anyway.

[(*1): And if we're worried about breaking existing usage, do we also
need to worry about someone with a script named "-p foo.gdb"?

bash$ cat ./"-p foo.gdb"
echo this is foo\n
bash$ gdb -quiet
(gdb) source -p foo.gdb
this is foo
(gdb) q
7.0.x-beta$

1/2 :-)]

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Date: Sun, 8 Feb 2009 17:52:46 -0800
> From: Doug Evans <dje@google.com>
> Cc: tromey@redhat.com, gdb-patches@sourceware.org
> 
> On Sat, Feb 7, 2009 at 8:08 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > However, I don't think I like the idea of GDB barfing if Python
> > support is not compiled in.  I think it should simply try to interpret
> > the file as GDB scripting commands.
> 
> I 3/4 disagree.  :-)
> 
> In the case of "source -p foo", I disagree.  This is new functionality
> (*1), and silently (or otherwise) interpreting "source -p foo" as gdb
> scripts will lead to subsequent breakage if/when python support does
> get compiled in.  [That's 1/2 of the 3/4.]
> 
> In the case of "source foo.py" I sort of disagree (that's the other 1/4, fwiw).
> Technically speaking it's possible that some bloke out there has a
> foo.py script that actually is gdb commands, and forcing the script to
> be interpreted as python would break that.  It's seems really unlikely
> though.
> 
> Perhaps "source" could/should also take a -g option to force the
> script to be interpreted as gdb commands.  It mightn't be sufficient
> to justify breaking an existing "source foo.py" being interpreted as
> gdb commands (though I think it is), but it might be reasonable to add
> anyway.
> 
> [(*1): And if we're worried about breaking existing usage, do we also
> need to worry about someone with a script named "-p foo.gdb"?

To clarify, I think "source" without Python compiled should behave
exactly as it did before this patch: treat foo.py as any other file
name and treat -p as it does today (i.e. source "-p foo.gdb" if it
exists).

Yes, this is called "backward compatibility".  It just could be that
one reason why someone configures GDB without Python is that they
don't want this incompatible change.

Re: RFC: add ability to "source" Python code

[Pedro Alves]

On Sunday 08 February 2009 01:16:10, Tom Tromey wrote:
> This patch adds Python support to the gdb "source" command.
> I added this after several user questions about how to do this.
> Also, due to completion, it is much more convenient than the
> equivalent "python" command.
> 
> With this patch, a file ending in ".py" is automatically treated as
> Python.  Also, other files can be interpreted as Python code by using
> the "-p" switch.  I made other switches into errors, on the theory
> that maybe we'd want to take more later ... I'm not sure if this is a
> good idea or not.
> 
> This patch also changes '-x' to accept .py files, as a side effect.
> 
> This could use a documentation review.  Also I'd appreciate any
> comments on it; it does change "source" incompatibly, though in a way
> that is very unlikely to affect users.
> 

I haven't played with the python stuff yet (shame on me!), but,
this got me curious on one thing.

Could you explain for the archives why this is better than having
the script itself tell GDB that it's running python?  Either
through something similar to a shebang, or starting the script with
"python" (does that work?) ?  I think you've discussed this before,
what were the limitations you found?

I'm thinking that as a user I don't usually care much scripting
language was used to implement a script -- it's an
implementation detail.

Say that in the future we add support for another scripting language
to GDB, and we want to keep the current python support working in
parallel.  As a matter of example, let's call it "Python 3.0".  Would
we want to add more "-p" switches to the source command?


> Built and regression tested on x86-64 (compile farm).
> New test case included.
> 
> Tom
> 
> 2009-02-07  Tom Tromey  <tromey@redhat.com>
> 
> 	* python/python.c (source_python_script): New function.
> 	* python/python.h (source_python_script): Declare.
> 	* cli/cli-cmds.c (find_argument): New function.
> 	(source_command): Use find_argument.  Handle -p argument.  Use
> 	make_cleanup_restore_integer.
> 	(source_verbose_cleanup): Remove.
> 	(source_python): New global.
> 	Include python.h.
> 	(init_cli_cmds): Update.
> 
> 2009-02-07  Tom Tromey  <tromey@redhat.com>
> 
> 	* gdb.texinfo (File Options): Document -x on .py files.
> 	(Command Files): Document source -p.
> 
> 2009-02-07  Tom Tromey  <tromey@redhat.com>
> 
> 	* gdb.base/help.exp: Update "source" help text.
> 	* gdb.python/source2.py: New file.
> 	* gdb.python/source1: New file.
> 	* gdb.python/python.exp: Test "source" command.
> 
> diff --git a/gdb/cli/cli-cmds.c b/gdb/cli/cli-cmds.c
> index 4d9c4f3..3713927 100644
> --- a/gdb/cli/cli-cmds.c
> +++ b/gdb/cli/cli-cmds.c
> @@ -45,6 +45,8 @@
>  #include "cli/cli-setshow.h"
>  #include "cli/cli-cmds.h"
>  
> +#include "python/python.h"
> +
>  #ifdef TUI
>  #include "tui/tui.h"		/* For tui_active et.al.   */
>  #endif
> @@ -178,6 +180,7 @@ struct cmd_list_element *showchecklist;
>  
>  /* Command tracing state.  */
>  
> +static int source_python = 0;
>  int source_verbose = 0;
>  int trace_commands = 0;
>  \f
> @@ -439,6 +442,7 @@ source_script (char *file, int from_tty)
>    struct cleanup *old_cleanups;
>    char *full_pathname = NULL;
>    int fd;
> +  int is_python;
>  
>    if (file == NULL || *file == 0)
>      {
> @@ -471,30 +475,44 @@ source_script (char *file, int from_tty)
>  	}
>      }
>  
> +  is_python = source_python;
> +  if (strlen (file) > 3 && !strcmp (&file[strlen (file) - 3], ".py"))
> +    is_python = 1;
> +
>    stream = fdopen (fd, FOPEN_RT);
> -  script_from_file (stream, file);
> +
> +  if (is_python)
> +    source_python_script (stream, file);
> +  else
> +    script_from_file (stream, file);
>  
>    do_cleanups (old_cleanups);
>  }
>  
> -/* Return the source_verbose global variable to its previous state
> -   on exit from the source command, by whatever means.  */
> -static void
> -source_verbose_cleanup (void *old_value)
> +/* A helper for source_command.  Look for an argument in *ARGS.
> +   Update *ARGS by stripping leading whitespace.  If an argument is
> +   found, return it (a character).  Otherwise, return 0.  */
> +static int
> +find_argument (char **args)
>  {
> -  source_verbose = *(int *)old_value;
> -  xfree (old_value);
> +  int result = 0;
> +  while (isspace ((*args)[0]))
> +    ++*args;
> +  if ((*args)[0] == '-' && isalpha ((*args)[1]))
> +    {
> +      result = (*args)[1];
> +      *args += 3;
> +    }
> +  return result;
>  }
>  
>  static void
>  source_command (char *args, int from_tty)
>  {
>    struct cleanup *old_cleanups;
> -  char *file = args;
> -  int *old_source_verbose = xmalloc (sizeof(int));
>  
> -  *old_source_verbose = source_verbose;
> -  old_cleanups = make_cleanup (source_verbose_cleanup, old_source_verbose);
> +  old_cleanups = make_cleanup_restore_integer (&source_verbose);
> +  make_cleanup_restore_integer (&source_python);
>  
>    /* -v causes the source command to run in verbose mode.
>       We still have to be able to handle filenames with spaces in a
> @@ -502,23 +520,28 @@ source_command (char *args, int from_tty)
>  
>    if (args)
>      {
> -      /* Make sure leading white space does not break the comparisons.  */
> -      while (isspace(args[0]))
> -	args++;
> -
> -      /* Is -v the first thing in the string?  */
> -      if (args[0] == '-' && args[1] == 'v' && isspace (args[2]))
> +      while (1)
>  	{
> -	  source_verbose = 1;
> -
> -	  /* Trim -v and whitespace from the filename.  */
> -	  file = &args[3];
> -	  while (isspace (file[0]))
> -	    file++;
> +	  int arg = find_argument (&args);
> +	  if (!arg)
> +	    break;
> +	  switch (arg)
> +	    {
> +	    case 'v':
> +	      source_verbose = 1;
> +	      break;
> +	    case 'p':
> +	      source_python = 1;
> +	      break;
> +	    default:
> +	      error (_("unrecognized option -%c"), arg);
> +	    }
>  	}
>      }
>  
> -  source_script (file, from_tty);
> +  source_script (args, from_tty);
> +
> +  do_cleanups (old_cleanups);
>  }
>  
>  
> @@ -1281,6 +1304,8 @@ Commands defined in this way may have up to ten arguments."));
>  Read commands from a file named FILE.\n\
>  Optional -v switch (before the filename) causes each command in\n\
>  FILE to be echoed as it is executed.\n\
> +Optional -p switch (before the filename) causes FILE to be evaluated\n\
> +as Python code.\n\
>  Note that the file \"%s\" is read automatically in this way\n\
>  when GDB is started."), gdbinit);
>    c = add_cmd ("source", class_support, source_command,
> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
> index 166b84d..e6472ae 100644
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -955,8 +955,10 @@ Connect to process ID @var{number}, as with the @code{attach} command.
>  @itemx -x @var{file}
>  @cindex @code{--command}
>  @cindex @code{-x}
> -Execute @value{GDBN} commands from file @var{file}.  @xref{Command
> -Files,, Command files}.
> +Execute commands from file @var{file}.  If @var{file} ends in
> +@samp{.py}, then the file is evaluated as Python code.  If Python
> +support is not enabled in this @value{GDBN}, then an error occurs.
> +@xref{Command Files,, Command files}.
>  
>  @item -eval-command @var{command}
>  @itemx -ex @var{command}
> @@ -17753,7 +17755,7 @@ command:
>  @table @code
>  @kindex source
>  @cindex execute commands from a file
> -@item source [@code{-v}] @var{filename}
> +@item source [@code{-v}] [@code{-p}] @var{filename}
>  Execute the command file @var{filename}.
>  @end table
>  
> @@ -17770,6 +17772,11 @@ If @code{-v}, for verbose mode, is given then @value{GDBN} displays
>  each command as it is executed.  The option must be given before
>  @var{filename}, and is interpreted as part of the filename anywhere else.
>  
> +If @var{filename} ends in @samp{.py}, or if @code{-p} (for ``Python'')
> +is given, then @value{GDBN} evaluates the contents of the file as
> +Python code.  If Python support is not compiled in to @value{GDBN},
> +then an error occurs.
> +
>  Commands that would ask for confirmation if used interactively proceed
>  without asking when used in a command file.  Many @value{GDBN} commands that
>  normally print messages to say what they are doing omit the messages
> diff --git a/gdb/python/python.c b/gdb/python/python.c
> index e778ac4..b275437 100644
> --- a/gdb/python/python.c
> +++ b/gdb/python/python.c
> @@ -273,6 +273,22 @@ execute_gdb_command (PyObject *self, PyObject *args)
>    Py_RETURN_NONE;
>  }
>  
> +/* Read a file as Python code.  STREAM is the input file; FILE is the
> +   name of the file.  */
> +
> +void
> +source_python_script (FILE *stream, char *file)
> +{
> +  PyGILState_STATE state;
> +
> +  state = PyGILState_Ensure ();
> +
> +  PyRun_SimpleFile (stream, file);
> +
> +  fclose (stream);
> +  PyGILState_Release (state);
> +}
> +
>  \f
>  
>  /* Printing.  */
> @@ -335,6 +351,13 @@ eval_python_from_control_command (struct command_line *cmd)
>    error (_("Python scripting is not supported in this copy of GDB."));
>  }
>  
> +void
> +source_python_script (FILE *stream)
> +{
> +  fclose (stream);
> +  error (_("Python scripting is not supported in this copy of GDB."));
> +}
> +
>  #endif /* HAVE_PYTHON */
>  
>  \f
> diff --git a/gdb/python/python.h b/gdb/python/python.h
> index e63c447..5a6a067 100644
> --- a/gdb/python/python.h
> +++ b/gdb/python/python.h
> @@ -26,4 +26,6 @@ extern struct value *values_in_python;
>  
>  void eval_python_from_control_command (struct command_line *);
>  
> +void source_python_script (FILE *stream, char *file);
> +
>  #endif /* GDB_PYTHON_H */
> diff --git a/gdb/testsuite/gdb.base/help.exp b/gdb/testsuite/gdb.base/help.exp
> index 4618a2c..ff2838a 100644
> --- a/gdb/testsuite/gdb.base/help.exp
> +++ b/gdb/testsuite/gdb.base/help.exp
> @@ -603,7 +603,7 @@ gdb_test "help stepi" "Step one instruction exactly\.\[\r\n\]+Argument N means d
>  gdb_test "help signal" "Continue program giving it signal.*" "help signal"
>  # test help source
>  # vxgdb reads .vxgdbinit
> -gdb_test "help source" "Read commands from a file named FILE\.\[\r\n\]+Optional -v switch \\(before the filename\\) causes each command in\[\r\n\]+FILE to be echoed as it is executed\.\[\r\n\]+Note that the file \"\[^\"\]*\" is read automatically in this way\[\r\n\]+when GDB is started\." "help source"
> +gdb_test "help source" "Read commands from a file named FILE\.\[\r\n\]+Optional -v switch \\(before the filename\\) causes each command in\[\r\n\]+FILE to be echoed as it is executed\.\[\r\n\]+Optional -p switch \\(before the filename\\) causes FILE to be evaluated\[\r\n\]+as Python code\\.\[\r\n\]+Note that the file \"\[^\"\]*\" is read automatically in this way\[\r\n\]+when GDB is started\." "help source"
>  # test help stack
>  test_class_help "stack" {
>      "Examining the stack\..*\[\r\n\]+"
> diff --git a/gdb/testsuite/gdb.python/python.exp b/gdb/testsuite/gdb.python/python.exp
> index a0c9b39..51c1a24 100644
> --- a/gdb/testsuite/gdb.python/python.exp
> +++ b/gdb/testsuite/gdb.python/python.exp
> @@ -71,3 +71,6 @@ gdb_py_test_multiple "indented multi-line python command" \
>    "  print 'hello, world!'" "" \
>    "foo ()" "" \
>    "end" "hello, world!"
> +
> +gdb_test "source -p $srcdir/$subdir/source1" "yes"
> +gdb_test "source $srcdir/$subdir/source2.py" "yes"
> diff --git a/gdb/testsuite/gdb.python/source1 b/gdb/testsuite/gdb.python/source1
> new file mode 100644
> index 0000000..b7ca419
> --- /dev/null
> +++ b/gdb/testsuite/gdb.python/source1
> @@ -0,0 +1,19 @@
> +#  This testcase is part of GDB, the GNU debugger.
> +
> +#  Copyright 2008, 2009 Free Software Foundation, Inc.
> +
> +#  This program is free software; you can redistribute it and/or modify
> +#  it under the terms of the GNU General Public License as published by
> +#  the Free Software Foundation; either version 3 of the License, or
> +#  (at your option) any later version.
> +
> +#  This program is distributed in the hope that it will be useful,
> +#  but WITHOUT ANY WARRANTY; without even the implied warranty of
> +#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +#  GNU General Public License for more details.
> +
> +#  You should have received a copy of the GNU General Public License
> +#  along with this program.  If not, see <http://www.gnu.org/licenses/>.
> +
> +# This is sourced as python; pick an expression that is not valid for gdb.
> +print 'y%ss' % 'e'
> diff --git a/gdb/testsuite/gdb.python/source2.py b/gdb/testsuite/gdb.python/source2.py
> new file mode 100644
> index 0000000..3d12222
> --- /dev/null
> +++ b/gdb/testsuite/gdb.python/source2.py
> @@ -0,0 +1,18 @@
> +#  This testcase is part of GDB, the GNU debugger.
> +
> +#  Copyright 2008, 2009 Free Software Foundation, Inc.
> +
> +#  This program is free software; you can redistribute it and/or modify
> +#  it under the terms of the GNU General Public License as published by
> +#  the Free Software Foundation; either version 3 of the License, or
> +#  (at your option) any later version.
> +
> +#  This program is distributed in the hope that it will be useful,
> +#  but WITHOUT ANY WARRANTY; without even the implied warranty of
> +#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +#  GNU General Public License for more details.
> +
> +#  You should have received a copy of the GNU General Public License
> +#  along with this program.  If not, see <http://www.gnu.org/licenses/>.
> +
> +print 'y%ss' % 'e'
> 



-- 
Pedro Alves

Re: RFC: add ability to "source" Python code

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> Could you explain for the archives why this is better than having
Pedro> the script itself tell GDB that it's running python?  Either
Pedro> through something similar to a shebang, or starting the script with
Pedro> "python" (does that work?) ?  I think you've discussed this before,
Pedro> what were the limitations you found?

I think you may be thinking of invoking a python script using
"#!.../gdb -something".  This patch does not cover that case.  That is
a separate patch, which I haven't submitted.

Anyway, I think having "source" look at a #! line would not be very
helpful.  Most Python source files do not start with this.

Yes, you can write:

  python
  blah blah blah
  end

in a file and then source that.  IME, this is not always convenient.

In practice, though, I find I use the .py extension feature a lot more
than "-p".  I can remove the "-p" feature if that will make you and
Eli and Doug happy.

Pedro> Say that in the future we add support for another scripting language
Pedro> to GDB, and we want to keep the current python support working in
Pedro> parallel.  As a matter of example, let's call it "Python 3.0".  Would
Pedro> we want to add more "-p" switches to the source command?

I don't think Python 3.0 is a good example.  I think we'll only be
able to link GDB against a single version of Python.

If someone adds other scripting languages to GDB, then yes, I would
support new a option to "source".  I would also support having
"source" know about common file extensions for the new language.

Tom

Re: RFC: add ability to "source" Python code

[Tom Tromey]

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> In the case of "source foo.py" I sort of disagree (that's the
Doug> other 1/4, fwiw).  Technically speaking it's possible that some
Doug> bloke out there has a foo.py script that actually is gdb
Doug> commands, and forcing the script to be interpreted as python
Doug> would break that.  It's seems really unlikely though.

I think it is beyond unlikely, and more in the realm of "has never
been done, ever, by any gdb user".

Doug> Perhaps "source" could/should also take a -g option to force the
Doug> script to be interpreted as gdb commands.

It would be fine by me.

Also I could add "--" to stop argument interpretation.
I don't think anybody will ever actually use this, but it would
make it obvious how to source a file with an odd name.

Well... most odd names.  You cannot source a file whose name ends in a
space.

Tom

Re: RFC: add ability to "source" Python code

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> To clarify, I think "source" without Python compiled should behave
Eli> exactly as it did before this patch: treat foo.py as any other file
Eli> name and treat -p as it does today (i.e. source "-p foo.gdb" if it
Eli> exists).

Eli> Yes, this is called "backward compatibility".  It just could be that
Eli> one reason why someone configures GDB without Python is that they
Eli> don't want this incompatible change.

I find this difficult to swallow.  This argument is that someone out
there finds the need to source a file named "-p something" so
compelling that he disables Python support rather than simply writing
"source ./-p something".

My view, instead, is that users generally do not use files with weird
names, or put gdb scripts into files with extensions clearly used by
other languages, or do other odd things like that.  And, if they do,
they will not mind renaming these files after a major release of GDB.

Major releases are when we can break some things in order to make GDB
better overall.  I do not think we should be constrained by scenarios
like this one, scenarios which, IMNSHO, have never once happened in
real life.

The reason I made the "source" command work the way I did is that it
is a familiar pattern to Unix users: you provide an option to get an
effect, and if the tool cannot provide that effect, you get an error.

Tom

Re: RFC: add ability to "source" Python code

[Pedro Alves]

On Tuesday 10 February 2009 01:27:32, Tom Tromey wrote:
> >>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
> 
> Pedro> Could you explain for the archives why this is better than having
> Pedro> the script itself tell GDB that it's running python?  Either
> Pedro> through something similar to a shebang, or starting the script with
> Pedro> "python" (does that work?) ?  I think you've discussed this before,
> Pedro> what were the limitations you found?
> 
> I think you may be thinking of invoking a python script using
> "#!.../gdb -something".  This patch does not cover that case.  That is
> a separate patch, which I haven't submitted.

I was thinking of the case of sourcing a python script from
inside gdb, not that.

> 
> Anyway, I think having "source" look at a #! line would not be very
> helpful.  Most Python source files do not start with this.
> 

OK then.

> Yes, you can write:
> 
>   python
>   blah blah blah
>   end
> 
> in a file and then source that.  IME, this is not always convenient.

Ah, I though I had heard mention that that this worked.  If experience
claims this isn't rightish, so be it.

> In practice, though, I find I use the .py extension feature a lot more
> than "-p".  I can remove the "-p" feature if that will make you and
> Eli and Doug happy.

Thanks for the explanations.  I'm happy with or without it.

-- 
Pedro Alves

Re: RFC: add ability to "source" Python code

[Daniel Jacobowitz]

On Tue, Feb 10, 2009 at 02:35:59AM +0000, Pedro Alves wrote:
> On Tuesday 10 February 2009 01:27:32, Tom Tromey wrote:
> > >>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
> > 
> > Pedro> Could you explain for the archives why this is better than having
> > Pedro> the script itself tell GDB that it's running python?  Either
> > Pedro> through something similar to a shebang, or starting the script with
> > Pedro> "python" (does that work?) ?  I think you've discussed this before,
> > Pedro> what were the limitations you found?
> > 
> > I think you may be thinking of invoking a python script using
> > "#!.../gdb -something".  This patch does not cover that case.  That is
> > a separate patch, which I haven't submitted.

I had something like "# *-python-*" in mind... :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Date: Mon, 9 Feb 2009 22:48:34 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
> 
> On Tue, Feb 10, 2009 at 02:35:59AM +0000, Pedro Alves wrote:
> > On Tuesday 10 February 2009 01:27:32, Tom Tromey wrote:
> > > >>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
> > > 
> > > Pedro> Could you explain for the archives why this is better than having
> > > Pedro> the script itself tell GDB that it's running python?  Either
> > > Pedro> through something similar to a shebang, or starting the script with
> > > Pedro> "python" (does that work?) ?  I think you've discussed this before,
> > > Pedro> what were the limitations you found?
> > > 
> > > I think you may be thinking of invoking a python script using
> > > "#!.../gdb -something".  This patch does not cover that case.  That is
> > > a separate patch, which I haven't submitted.
> 
> I had something like "# *-python-*" in mind... :-)

Yes.  I think this is by far the best solution, one that will keep
back compatibility without hampering any of the new and valuable
Python features.

Can we agree on using such cookies in GDB scripts written in Python?
Then we won't need the -p switch or the .py extension detection.

Re: RFC: add ability to "source" Python code

[Thiago Jung Bauermann]

El mar, 10-02-2009 a las 11:34 +0200, Eli Zaretskii escribió:
> > Date: Mon, 9 Feb 2009 22:48:34 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
> > > > I think you may be thinking of invoking a python script using
> > > > "#!.../gdb -something".  This patch does not cover that case.  That is
> > > > a separate patch, which I haven't submitted.
> > 
> > I had something like "# *-python-*" in mind... :-)
> 
> Yes.  I think this is by far the best solution, one that will keep
> back compatibility without hampering any of the new and valuable
> Python features.
> 
> Can we agree on using such cookies in GDB scripts written in Python?
> Then we won't need the -p switch or the .py extension detection.

I don't mind GDB detecting that string in the beginning of a Python
script. But I am strongly against dropping filename extension detection
in favour of that.

I've never written a Python script (in GDB or otherwise) with that
markup, but *all* the Python scripts I ever wrote in my life ended
in .py. It'd be just counter-intuitive and counter productive to not
support the filename extension.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: RFC: add ability to "source" Python code

[Tom Tromey]

>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> writes:

Thiago> I've never written a Python script (in GDB or otherwise) with that
Thiago> markup, but *all* the Python scripts I ever wrote in my life ended
Thiago> in .py. It'd be just counter-intuitive and counter productive to not
Thiago> support the filename extension.

Yes, I agree.

However, due to the controversy, I'm withdrawing this patch.  I guess
users can use "python execfile".

Tom

Re: RFC: add ability to "source" Python code

[Paul Pluzhnikov]

On Tue, Feb 10, 2009 at 9:02 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> writes:
>
> Thiago> I've never written a Python script (in GDB or otherwise) with that
> Thiago> markup, but *all* the Python scripts I ever wrote in my life ended
> Thiago> in .py. It'd be just counter-intuitive and counter productive to not
> Thiago> support the filename extension.
>
> Yes, I agree.
>
> However, due to the controversy, I'm withdrawing this patch.  I guess
> users can use "python execfile".

I'd like to push for this patch a little harder...

It is true, users could just type:

  python execfile("/path/to/script.py")

(and loose file-name completion) instead of

  source /path/to/script.py

or prefix each one of their foo.py scripts with "python", but why
make them?

It seems to me that we are trading end-user convenience (after all,
you put this patch in because it was convenient for us all to use
"source" like that!) for largely theoretical backwards compatibility
problem.

-- 
Paul Pluzhnikov

Re: RFC: add ability to "source" Python code

[Joel Brobecker]

(sorry for jumping late in the conversation, computer troubles :-( )
> Thiago> I've never written a Python script (in GDB or otherwise) with that
> Thiago> markup, but *all* the Python scripts I ever wrote in my life ended
> Thiago> in .py. It'd be just counter-intuitive and counter productive to not
> Thiago> support the filename extension.
> 
> Yes, I agree.

I also agree! I support Tom's proposed behavior, and I don't think
we even need the "-p" switch. Honestly, anyone naming a GDB script
file with a .py extension, knowing that .py is a standard extension
for a widely used language, is just shooting himself in the foot.

> However, due to the controversy, I'm withdrawing this patch.  I guess
> users can use "python execfile".

Withdrawal refused (ahem, I'm trying to make it sound like a boss that
refuses the resignation of one of his employees :-). I'd also like
to push for this patch a little more, as I do find the new behavior much
much easier than the "python exec (...)" approach.  I don't find the
idea of turning the python script into a GDB script with embedded python
code in it too appealing either.

-- 
Joel

Re: RFC: add ability to "source" Python code

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Tom> However, due to the controversy, I'm withdrawing this patch.  I guess
Tom> users can use "python execfile".

Joel> Withdrawal refused (ahem, I'm trying to make it sound like a
Joel> boss that refuses the resignation of one of his employees :-).

:-)

My reading of the thread is that there are three active proposals.
One is the patch (perhaps without the -p flag), one is the patch but
strictly preserving backward compatibility in the no-Python case, and
one is the cookie idea.

I do not like the cookie idea, because it is breaking new ground: few
existing Python sources use an Emacs-style cookie.

I do not like the backward compatibility proposal because I think it
makes gdb less predictable.

I also do not want to override the objections of other maintainers.
This is more important to me than this feature.

That is why I think we are at an impasse.  Perhaps I read too much
into the various replies -- that is easily corrected by more replies :-)

Tom

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>, Eli Zaretskii <eliz@gnu.org>,
>         Daniel Jacobowitz <drow@false.org>, pedro@codesourcery.com,
>         gdb-patches@sourceware.org
> From: Tom Tromey <tromey@redhat.com>
> Date: Wed, 11 Feb 2009 12:48:59 -0700
> 
> I do not like the cookie idea

Considering that this is the only alternative proposed so far that has
the most chances to be accepted, and that it is 100% backwards
compatible, perhaps you could reconsider.

Re: RFC: add ability to "source" Python code

[Joel Brobecker]

> > I do not like the cookie idea
> 
> Considering that this is the only alternative proposed so far that has
> the most chances to be accepted, and that it is 100% backwards
> compatible, perhaps you could reconsider.

Perhaps, but I believe that it makes the feature much much less useful
that it would be. I'd like to be able to grab a Python script, any
python script, and evaluate it in GDB.  For instance, if I have a Python
script that doesn't do anything GDB specific, I'd like to be able to
evaluate it without having to add the cookie.

I think that we're being much too strict in applying the compatibility
principle in this case.  I mean, what are the chances of someone naming
a GDB script with a .py extension? I think it's perfectly fine to tell
the few people who might have done so to rename their files (or stay
with GDB 6.x). We're not trying to be perfect, we're trying to do what's
going to be more useful in most cases.

-- 
Joel

Re: RFC: add ability to "source" Python code

[Daniel Jacobowitz]

On Wed, Feb 11, 2009 at 10:21:00PM +0200, Eli Zaretskii wrote:
> Considering that this is the only alternative proposed so far that has
> the most chances to be accepted, and that it is 100% backwards
> compatible, perhaps you could reconsider.

I've been successfully convinced that this would be a bad idea.

Could you explain why you think GDB should try to parse files
with Python extensions as CLI scripts?  I can't think of any
case where this would be useful.

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: add ability to "source" Python code

[Joel Brobecker]

> I also do not want to override the objections of other maintainers.
> This is more important to me than this feature.

Of course. Generally speaking, a disagreement is something that will
happen once in a while. Now, we need to determine how strong the
objections are. Sometimes, if they are only mild objections, perhaps
we'll have to decide as a group that we want to move forward, even
if some of us think that the solution is not ideal.

In this specific situation, I am hoping that we haven't reached
the point where we are no longer listening to each other. That's
why I am keen on continuing the discussion a little longer.

-- 
Joel

Re: RFC: add ability to "source" Python code

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> Considering that this is the only alternative proposed so far that has
Eli> the most chances to be accepted, and that it is 100% backwards
Eli> compatible, perhaps you could reconsider.

Pedantically speaking, it is not compatible.  Anybody can write that
comment in their .gdbinit today.

I don't really see a fundamental difference between compatibility of
file contents and compatibility of file extensions -- I consider them
both rather silly.  But, in order to argue this way, I think you ought
to explain why the disparity is ok.

I stand by my view of the situation.  That is why I withdrew the
patch.  I respect others' views on this and, in return, I expect mine
to be respected.

Tom

Re: RFC: add ability to "source" Python code

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> Of course. Generally speaking, a disagreement is something that will
Joel> happen once in a while. Now, we need to determine how strong the
Joel> objections are. Sometimes, if they are only mild objections, perhaps
Joel> we'll have to decide as a group that we want to move forward, even
Joel> if some of us think that the solution is not ideal.

Yes, I agree.  Another way I look at this is ranking preferences:
sometimes one might prefer no change above a change one disagrees
with.  Other times, that may not be the case.

It can be difficult to get this information from a comment on a patch.
I tend to err on the verbose side for this reason, but sending
follow-up comments is also a good way to make one's preferences known.

Tom

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Date: Wed, 11 Feb 2009 12:39:21 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Tom Tromey <tromey@redhat.com>, bauerman@br.ibm.com, drow@false.org,
> 	pedro@codesourcery.com, gdb-patches@sourceware.org
> 
> > > I do not like the cookie idea
> > 
> > Considering that this is the only alternative proposed so far that has
> > the most chances to be accepted, and that it is 100% backwards
> > compatible, perhaps you could reconsider.
> 
> Perhaps, but I believe that it makes the feature much much less useful
> that it would be.

I think that's a heck of exaggeration.  We are talking about adding a
single line.

> I'd like to be able to grab a Python script, any python script, and
> evaluate it in GDB.

Doesn't that work with "python FOO" right now?

Also, would an arbitrary Python script necessarily do anything useful
in GDB?  Some of them probably will, but not just any one, I think.

> what are the chances of someone naming a GDB script with a .py
> extension?

No less than the chances of someone grabbing any Python script and
evaluating in GDB, I presume.

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Date: Wed, 11 Feb 2009 15:42:49 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Tom Tromey <tromey@redhat.com>, brobecker@adacore.com,
> 	bauerman@br.ibm.com, pedro@codesourcery.com,
> 	gdb-patches@sourceware.org
> 
> On Wed, Feb 11, 2009 at 10:21:00PM +0200, Eli Zaretskii wrote:
> > Considering that this is the only alternative proposed so far that has
> > the most chances to be accepted, and that it is 100% backwards
> > compatible, perhaps you could reconsider.
> 
> I've been successfully convinced that this would be a bad idea.
> 
> Could you explain why you think GDB should try to parse files
> with Python extensions as CLI scripts?  I can't think of any
> case where this would be useful.

I already explained that.

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Cc: brobecker@adacore.com, bauerman@br.ibm.com, drow@false.org,
>         pedro@codesourcery.com, gdb-patches@sourceware.org
> From: Tom Tromey <tromey@redhat.com>
> Date: Wed, 11 Feb 2009 13:51:41 -0700
> 
> I respect others' views on this and, in return, I expect mine to be
> respected.

I hope what I wrote shows no disrespect whatsoever.  If it did, I
apologize.

Re: RFC: add ability to "source" Python code

[Daniel Jacobowitz]

On Wed, Feb 11, 2009 at 11:08:06PM +0200, Eli Zaretskii wrote:
> > Could you explain why you think GDB should try to parse files
> > with Python extensions as CLI scripts?  I can't think of any
> > case where this would be useful.
> 
> I already explained that.

Is this what you're referring to, or am I missing a further explanation?

> Yes, this is called "backward compatibility".  It just could be that
> one reason why someone configures GDB without Python is that they
> don't want this incompatible change.

This argument would prevent us ever adding new commands or changing
the behavior of a command without adding a configure option for them.
The CLI already evolves over time; I don't think this level of
compatibility is a realistic goal for us.

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFC: add ability to "source" Python code

[Matt Rice]

On Wed, Feb 11, 2009 at 1:06 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> Also, would an arbitrary Python script necessarily do anything useful
> in GDB?  Some of them probably will, but not just any one, I think.
>

Yes,

(gdb) python execfile("/home/ratmice/bar.py")
(gdb) python foo()
foo

where the foo function is defined in bar.py.
so it acts just like 'source' in a shell i would imagine.

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Date: Wed, 11 Feb 2009 16:14:18 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: tromey@redhat.com, brobecker@adacore.com, bauerman@br.ibm.com,
> 	pedro@codesourcery.com, gdb-patches@sourceware.org
> 
> > Yes, this is called "backward compatibility".  It just could be that
> > one reason why someone configures GDB without Python is that they
> > don't want this incompatible change.
> 
> This argument would prevent us ever adding new commands or changing
> the behavior of a command without adding a configure option for them.

We are not adding a new command, we are modifying behavior of an old
one in a gratuitously incompatible way.

I don't mind adding a new command, because invoking nonexistent
commands generally produces an error.  So chances of breaking existing
scripts are all but non-existent.  But here we are talking about
breaking something that works today without any error message, and
that's another story.

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Date: Wed, 11 Feb 2009 13:25:40 -0800
> From: Matt Rice <ratmice@gmail.com>
> Cc: Joel Brobecker <brobecker@adacore.com>, tromey@redhat.com, bauerman@br.ibm.com,  	drow@false.org, pedro@codesourcery.com, gdb-patches@sourceware.org
> 
> On Wed, Feb 11, 2009 at 1:06 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Also, would an arbitrary Python script necessarily do anything useful
> > in GDB?  Some of them probably will, but not just any one, I think.
> >
> 
> Yes,
> 
> (gdb) python execfile("/home/ratmice/bar.py")
> (gdb) python foo()
> foo
> 
> where the foo function is defined in bar.py.
> so it acts just like 'source' in a shell i would imagine.

Sorry, I don't understand how this is related.  Perhaps it's too late
and I should go to sleep.

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Date: Wed, 11 Feb 2009 23:48:26 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: brobecker@adacore.com, tromey@redhat.com, bauerman@br.ibm.com, drow@false.org, pedro@codesourcery.com, gdb-patches@sourceware.org
> 
> > Date: Wed, 11 Feb 2009 13:25:40 -0800
> > From: Matt Rice <ratmice@gmail.com>
> > Cc: Joel Brobecker <brobecker@adacore.com>, tromey@redhat.com, bauerman@br.ibm.com,  	drow@false.org, pedro@codesourcery.com, gdb-patches@sourceware.org
> > 
> > On Wed, Feb 11, 2009 at 1:06 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > Also, would an arbitrary Python script necessarily do anything useful
> > > in GDB?  Some of them probably will, but not just any one, I think.
> > >
> > 
> > Yes,
> > 
> > (gdb) python execfile("/home/ratmice/bar.py")
> > (gdb) python foo()
> > foo
> > 
> > where the foo function is defined in bar.py.
> > so it acts just like 'source' in a shell i would imagine.
> 
> Sorry, I don't understand how this is related.

I mean I don't understand how printing "foo" is doing "something
useful in GDB".

Re: RFC: add ability to "source" Python code

[Joel Brobecker]

OK, this is going to be my final message on the subject. This is not
sufficiently important for me to spend more energy on this.

> > Perhaps, but I believe that it makes the feature much much less useful
> > that it would be.
> 
> I think that's a heck of exaggeration.  We are talking about adding a
> single line.

I could return the "heck of exaggeration" back by saying that we're only
talking about the highly improbably GDB scripts whose name uses a standard
Python extension. Perhaps we should do a poll on gdb asking if anyone
has a GDB script that has such an extension?

> > I'd like to be able to grab a Python script, any python script, and
> > evaluate it in GDB.
> 
> Doesn't that work with "python FOO" right now?

No, you have to do (IIRC):

    (gdb) python execfile ("/my/python/script.py")

> Also, would an arbitrary Python script necessarily do anything useful
> in GDB?  Some of them probably will, but not just any one, I think.

Maybe not anything, but yes, some of them. I'm starting to use Python
more and more and my collection of scripts is slowly building up.
Some of them setup environments, etc.

-- 
Joel

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Date: Wed, 11 Feb 2009 14:01:18 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: tromey@redhat.com, bauerman@br.ibm.com, drow@false.org, 	pedro@codesourcery.com, gdb-patches@sourceware.org
> 
> > > Perhaps, but I believe that it makes the feature much much less useful
> > > that it would be.
> > 
> > I think that's a heck of exaggeration.  We are talking about adding a
> > single line.
> 
> I could return the "heck of exaggeration" back by saying that we're only
> talking about the highly improbably GDB scripts whose name uses a standard
> Python extension.

Yes, but I didn't say that makes the feature "much less useful".  I
just said that I didn't like the incompatibility.

Re: RFC: add ability to "source" Python code

[Joel Brobecker]

> > I could return the "heck of exaggeration" back by saying that we're only
> > talking about the highly improbably GDB scripts whose name uses a standard
> > Python extension.
> 
> Yes, but I didn't say that makes the feature "much less useful".  I
> just said that I didn't like the incompatibility.

I did mean what I said, and I don't think it's an exageration.
Otherwise, I wouldn't be even arguing about it. I am OK with you
not agreeing with that judgement, but you do make it sound like
I'm obviously wrong. I cannot be that obvious, given the number of
people who expressed their opinion in favor of this feature, vs
the number of people against.

Anyway, how about a compromise, then, and require the -p switch to
source python scripts? The incompatibility is that

   (gdb) source -p foo

would no longer work for file "-p foo". I think that's an acceptable
"incompatibilty". Would you agree?

-- 
Joel

Re: RFC: add ability to "source" Python code

[Thiago Jung Bauermann]

El mié, 11-02-2009 a las 22:26 -0800, Joel Brobecker escribió:
> > > I could return the "heck of exaggeration" back by saying that we're only
> > > talking about the highly improbably GDB scripts whose name uses a standard
> > > Python extension.
> > 
> > Yes, but I didn't say that makes the feature "much less useful".  I
> > just said that I didn't like the incompatibility.
> 
> I did mean what I said, and I don't think it's an exageration.
> Otherwise, I wouldn't be even arguing about it. I am OK with you
> not agreeing with that judgement, but you do make it sound like
> I'm obviously wrong. I cannot be that obvious, given the number of
> people who expressed their opinion in favor of this feature, vs
> the number of people against.

For the record, I agree with Joel in that not recognizing .py makes the
feature much less useful.

> Anyway, how about a compromise, then, and require the -p switch to
> source python scripts? The incompatibility is that
> 
>    (gdb) source -p foo
> 
> would no longer work for file "-p foo". I think that's an acceptable
> "incompatibilty". Would you agree?

+1
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Date: Wed, 11 Feb 2009 22:26:54 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: tromey@redhat.com, bauerman@br.ibm.com, drow@false.org, 	pedro@codesourcery.com, gdb-patches@sourceware.org
> 
> > > I could return the "heck of exaggeration" back by saying that we're only
> > > talking about the highly improbably GDB scripts whose name uses a standard
> > > Python extension.
> > 
> > Yes, but I didn't say that makes the feature "much less useful".  I
> > just said that I didn't like the incompatibility.
> 
> I did mean what I said, and I don't think it's an exageration.
> Otherwise, I wouldn't be even arguing about it. I am OK with you
> not agreeing with that judgement, but you do make it sound like
> I'm obviously wrong. I cannot be that obvious

Joel, please read what I wrote, not what you think I said:

    > Perhaps, but I believe that it makes the feature much much less useful
    > that it would be.

    I think that's a heck of exaggeration.  We are talking about adding a
    single line.

As you see, I didn't say you were obviously wrong.  In fact, I didn't
even say you were wrong at all, just that "much less useful" was an
exaggeration, which is a far cry.

> Anyway, how about a compromise, then, and require the -p switch to
> source python scripts? The incompatibility is that
> 
>    (gdb) source -p foo
> 
> would no longer work for file "-p foo". I think that's an acceptable
> "incompatibilty". Would you agree?

This is a misunderstanding: I didn't mind the -p switch, I mind the
fact that it throws an error if Python is not compiled in.  Eliminate
the error, and you have me on board.

Re: RFC: add ability to "source" Python code

[Joel Brobecker]

> > Anyway, how about a compromise, then, and require the -p switch to
> > source python scripts? The incompatibility is that
> > 
> >    (gdb) source -p foo
> > 
> > would no longer work for file "-p foo". I think that's an acceptable
> > "incompatibilty". Would you agree?
> 
> This is a misunderstanding: I didn't mind the -p switch, I mind the
> fact that it throws an error if Python is not compiled in.  Eliminate
> the error, and you have me on board.

Cool! So, just to make sure I understand what you're saying, you would
agree to the following change:

Add a -p switch to the "source" command that signifies that we're sourcing
a python script instead of a GDB script. We drop the part where we're
using the filename extension to guess the file language, thus preserving
the current behavior.

Finally, what should we do if trying to source a python script with
a debugger that does not have python linked in? Treat the -p switch
as part of the script filename? (I would find this really odd)

-- 
Joel

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Date: Thu, 12 Feb 2009 18:22:46 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: tromey@redhat.com, bauerman@br.ibm.com, drow@false.org,
> 	pedro@codesourcery.com, gdb-patches@sourceware.org
> 
> > > Anyway, how about a compromise, then, and require the -p switch to
> > > source python scripts? The incompatibility is that
> > > 
> > >    (gdb) source -p foo
> > > 
> > > would no longer work for file "-p foo". I think that's an acceptable
> > > "incompatibilty". Would you agree?
> > 
> > This is a misunderstanding: I didn't mind the -p switch, I mind the
> > fact that it throws an error if Python is not compiled in.  Eliminate
> > the error, and you have me on board.
> 
> Cool! So, just to make sure I understand what you're saying, you would
> agree to the following change:
> 
> Add a -p switch to the "source" command that signifies that we're sourcing
> a python script instead of a GDB script. We drop the part where we're
> using the filename extension to guess the file language, thus preserving
> the current behavior.

Yes.  I would even agree to retaining the language guesswork by
file-name extension, provided that (a) there's a user option to turn
that on and off, and (b) that option is off and stays off when Python
is not compiled in.

> Finally, what should we do if trying to source a python script with
> a debugger that does not have python linked in? Treat the -p switch
> as part of the script filename? (I would find this really odd)

Ideally, it should work as it does today, but if that's too hard to
implement, how about simply ignoring -p in that case?  That is, let
"source -p foo" behave like "source foo".

On the slim chance that this somewhat heated discussion was due to a
similar misunderstanding, I dare to quote what I originally wrote:

    However, I don't think I like the idea of GDB barfing if Python
    support is not compiled in.  I think it should simply try to interpret
    the file as GDB scripting commands.

and

    To clarify, I think "source" without Python compiled should behave
    exactly as it did before this patch: treat foo.py as any other file
    name and treat -p as it does today (i.e. source "-p foo.gdb" if it
    exists).

Now I add to this the suggestion to have a user variable as described
above.  Hopefully, somewhere in between we will be able to find a
compromise that won't cause any of us to storm out of the premises ;-)

Re: RFC: add ability to "source" Python code

[Joel Brobecker]

> > Add a -p switch to the "source" command that signifies that we're sourcing
> > a python script instead of a GDB script. We drop the part where we're
> > using the filename extension to guess the file language, thus preserving
> > the current behavior.
> 
> Yes.  I would even agree to retaining the language guesswork by
> file-name extension, provided that (a) there's a user option to turn
> that on and off, and (b) that option is off and stays off when Python
> is not compiled in.

OK, I think I see now why we could not agree in the past, and I feel
that it will help in finding an agreeable solution.

> Ideally, it should work as it does today, but if that's too hard to
> implement, how about simply ignoring -p in that case?  That is, let
> "source -p foo" behave like "source foo".

I personally think it's a mistake to have a different behavior
based on how GDB was built, and that causing an error is less confusing.
But I'd be OK with the behavior you propose (no error, just the original
behavior).

Let's see what everyone thinks. I have several issues that I'd like
to discuss before we can finalize a proposal:

  1. If we have filename-extension detection (controlled by a setting),
     do we need the "-p" switch at all? If we agreed that it's an
     acceptable limitation that python scripts in GDB should have
     a .py extension, then we don't really need the .py switch,
     do we?  This in turn would side-step the question of what to do
     with -p when python wasn't compiled in.

  2. Are others OK with interpreting all files as GDB scripts when
     python wasn't compiled in, even files with a .py extension?
     
     Or maybe, how about changing the semantics of that setting
     to apply to files that are detected as python (regardless of
     how the detection is performed): In one case these files are
     sourced as python script, but on the other, these files are
     still treated as GDB scripts. When GDB was built with python,
     then this switch can be used to turn the new feature off,
     whereas if no python was available, the setting would be stuck
     to the value where files are sourced as GDB scripts.

Now that I've written all this and that it has given me a chance
to think this over a little more, I like the idea of falling back
to GDB scripts less and less. So much so that I'm wondering whether
using a different command than "source" might be better? "pysource"
for instance?

-- 
Joel

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Date: Mon, 16 Feb 2009 16:07:46 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: tromey@redhat.com, bauerman@br.ibm.com, drow@false.org,
> 	pedro@codesourcery.com, gdb-patches@sourceware.org
> 
> Let's see what everyone thinks. I have several issues that I'd like
> to discuss before we can finalize a proposal:

My responses below.

>   1. If we have filename-extension detection (controlled by a setting),
>      do we need the "-p" switch at all? If we agreed that it's an
>      acceptable limitation that python scripts in GDB should have
>      a .py extension, then we don't really need the .py switch,
>      do we?  This in turn would side-step the question of what to do
>      with -p when python wasn't compiled in.

I'm okay with this, but I think Tom had some valid reasons for having
Python scripts that don't have a certain extension.

>      Or maybe, how about changing the semantics of that setting
>      to apply to files that are detected as python (regardless of
>      how the detection is performed): In one case these files are
>      sourced as python script, but on the other, these files are
>      still treated as GDB scripts. When GDB was built with python,
>      then this switch can be used to turn the new feature off,
>      whereas if no python was available, the setting would be stuck
>      to the value where files are sourced as GDB scripts.

Fine with me.

> Now that I've written all this and that it has given me a chance
> to think this over a little more, I like the idea of falling back
> to GDB scripts less and less. So much so that I'm wondering whether
> using a different command than "source" might be better? "pysource"
> for instance?

I think there is already a way to do that: the `python' command.  I
think the `source' proposal was intended to treat Python scripts more
similar to GDB scripts, and I generally agree with that idea,
i.e. that we should have a single command that sources scripts.

Re: RFC: add ability to "source" Python code

[Tom Tromey]

Joel> 1. If we have filename-extension detection (controlled by a
Joel> setting), do we need the "-p" switch at all?

Eli> I'm okay with this, but I think Tom had some valid reasons for
Eli> having Python scripts that don't have a certain extension.

It is a convenience when using scratch files.
In practice I don't use -p much.  I don't mind removing it.

Joel> Now that I've written all this and that it has given me a chance
Joel> to think this over a little more, I like the idea of falling back
Joel> to GDB scripts less and less. So much so that I'm wondering whether
Joel> using a different command than "source" might be better? "pysource"
Joel> for instance?

I considered this early on and rejected it, because "source" is
clearer and "felt natural".

FWIW you can write pysource in a few lines of Python, if you really
want to go that route.  People who miss the "source" feature can just
do this themselves.

Thanks for trying to find a compromise solution.

Tom

Re: RFC: add ability to "source" Python code

[Joel Brobecker]

> Eli> I'm okay with this, but I think Tom had some valid reasons for
> Eli> having Python scripts that don't have a certain extension.
> 
> It is a convenience when using scratch files.
> In practice I don't use -p much.  I don't mind removing it.

Ok, we can try without, and see if we get any request?

> I considered this early on and rejected it, because "source" is
> clearer and "felt natural".

Yeah ... I would have to agree with that.

So, where do you think we should go from now?
a tri-state setting:

  1. Use filename extension and evaluate accordingly.
     Error if the language was not compiled in.

  2, Use filename extension and evaluate accordingly.
     Fallback to GDB scripting if the language was not compiled in.

  3. No filename extension recognition, always treat sourced files
     as GDB scripts.

Would that be acceptable to everyone?

Otherwise, I'd be OK with a two state that just deactivates filename
extension recognition, and implements option (2) above when turned on,
but for some reason this fallback, which causes GDBs of the same version
to behavior differently, feels VERY wrong to me. So I'd like to have
a setting that allows me to provide behavior (1).

-- 
Joel

Re: RFC: add ability to "source" Python code

[Thiago Jung Bauermann]

Hi folks,

I'm resurrecting this old thread. I believe it is important that we
settle this discussion before 7.0.

Em Qui, 2009-02-19 às 12:05 -0800, Joel Brobecker escreveu:
> > Eli> I'm okay with this, but I think Tom had some valid reasons for
> > Eli> having Python scripts that don't have a certain extension.
> > 
> > It is a convenience when using scratch files.
> > In practice I don't use -p much.  I don't mind removing it.
> 
> Ok, we can try without, and see if we get any request?

Agreed. I don't care much about -p either.

> So, where do you think we should go from now?
> a tri-state setting:
> 
>   1. Use filename extension and evaluate accordingly.
>      Error if the language was not compiled in.
> 
>   2, Use filename extension and evaluate accordingly.
>      Fallback to GDB scripting if the language was not compiled in.
> 
>   3. No filename extension recognition, always treat sourced files
>      as GDB scripts.
> 
> Would that be acceptable to everyone?

This patch implements such tri-state setting:

(gdb) help set script-extension
Set mode for script filename extension recognition.
off  == no filename extension recognition (all sourced files are GDB scripts)
soft == evaluate script according to filename extension, fallback to GDB script
hard == evaluate script according to filename extension, error if not supported

The default is 'soft'. When Python support is not compiled in, the code
always assumes a GDB script.

Is this good enough for everybody? Please ignore the documentation part
of the patch, I'll only update it when we have the code part ready to
commit.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center


2009-06-01  Tom Tromey  <tromey@redhat.com>
	    Thiago Jung Bauermann  <bauerman@br.ibm.com>

	* python/python.c (source_python_script): New function.
	* python/python.h (source_python_script): Declare.
	* cli/cli-cmds.c (find_argument): New function.
	(source_command): Use find_argument.  Handle -p argument.  Use
	make_cleanup_restore_integer.
	(source_verbose_cleanup): Remove.
	(source_python): New global.
	Include python.h.
	(init_cli_cmds): Update.

2009-06-01  Tom Tromey  <tromey@redhat.com>

	* gdb.texinfo (File Options): Document -x on .py files.
	(Command Files): Document source -p.

2009-06-01  Tom Tromey  <tromey@redhat.com>
	    Thiago Jung Bauermann  <bauerman@br.ibm.com>

	* gdb.base/help.exp: Update "source" help text.
	* gdb.python/source2.py: New file.
	* gdb.python/source1: New file.
	* gdb.python/python.exp: Test "source" command.

Index: gdb.git/gdb/cli/cli-cmds.c
===================================================================
--- gdb.git.orig/gdb/cli/cli-cmds.c	2009-06-01 00:51:11.000000000 -0300
+++ gdb.git/gdb/cli/cli-cmds.c	2009-06-01 00:52:37.000000000 -0300
@@ -19,6 +19,7 @@
    along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
 #include "defs.h"
+#include "exceptions.h"
 #include "readline/readline.h"
 #include "readline/tilde.h"
 #include "completer.h"
@@ -45,6 +46,8 @@
 #include "cli/cli-setshow.h"
 #include "cli/cli-cmds.h"
 
+#include "python/python.h"
+
 #ifdef TUI
 #include "tui/tui.h"		/* For tui_active et.al.   */
 #endif
@@ -181,6 +184,21 @@ struct cmd_list_element *showchecklist;
 int source_verbose = 0;
 int trace_commands = 0;
 \f
+/* 'script-extension' option support.  */
+
+static const char script_ext_off[] = "off";
+static const char script_ext_soft[] = "soft";
+static const char script_ext_hard[] = "hard";
+
+static const char *script_ext_enums[] = {
+  script_ext_off,
+  script_ext_soft,
+  script_ext_hard,
+  NULL
+};
+
+static const char *script_ext_mode = script_ext_soft;
+\f
 /* Utility used everywhere when at least one argument is needed and
    none is supplied. */
 
@@ -432,18 +450,25 @@ cd_command (char *dir, int from_tty)
     pwd_command ((char *) 0, 1);
 }
 \f
-void
-source_script (char *file, int from_tty)
+/* Show the current value of the 'script-extension' option.  */
+
+static void
+show_script_ext_mode (struct ui_file *file, int from_tty,
+		     struct cmd_list_element *c, const char *value)
 {
-  FILE *stream;
-  struct cleanup *old_cleanups;
+  fprintf_filtered (file, _("\
+Script filename extension recognition is \"%s\".\n"),
+		    value);
+}
+
+static int
+find_and_open_script (int from_tty, char **filep, FILE **streamp,
+		      struct cleanup **cleanupp)
+{
+  char *file = *filep;
   char *full_pathname = NULL;
   int fd;
-
-  if (file == NULL || *file == 0)
-    {
-      error (_("source command requires file name of file to source."));
-    }
+  struct cleanup *old_cleanups;
 
   file = tilde_expand (file);
   old_cleanups = make_cleanup (xfree, file);
@@ -467,12 +492,58 @@ source_script (char *file, int from_tty)
       else
 	{
 	  do_cleanups (old_cleanups);
-	  return;
+	  return 0;
 	}
     }
 
-  stream = fdopen (fd, FOPEN_RT);
-  script_from_file (stream, file);
+  *streamp = fdopen (fd, FOPEN_RT);
+  *filep = file;
+  *cleanupp = old_cleanups;
+
+  return 1;
+}
+
+void
+source_script (char *file, int from_tty)
+{
+  FILE *stream;
+  struct cleanup *old_cleanups;
+
+  if (file == NULL || *file == 0)
+    {
+      error (_("source command requires file name of file to source."));
+    }
+
+  if (!find_and_open_script (from_tty, &file, &stream, &old_cleanups))
+    return;
+
+  if (script_ext_mode != script_ext_off
+      && strlen (file) > 3 && !strcmp (&file[strlen (file) - 3], ".py"))
+    {
+      volatile struct gdb_exception e;
+
+      TRY_CATCH (e, RETURN_MASK_ERROR)
+	{
+	  source_python_script (stream, file);
+	}
+      if (e.reason < 0)
+	{
+	  /* Should we fallback to ye olde GDB script mode?  */
+	  if (script_ext_mode == script_ext_soft
+	      && e.reason == RETURN_ERROR && e.error == UNSUPPORTED_ERROR)
+	    {
+	      if (!find_and_open_script (from_tty, &file, &stream, &old_cleanups))
+		return;
+
+	      script_from_file (stream, file);
+	    }
+	  else
+	    /* Nope, just punt.  */
+	    throw_exception (e);
+	}
+    }
+  else
+    script_from_file (stream, file);
 
   do_cleanups (old_cleanups);
 }
@@ -1286,6 +1357,19 @@ when GDB is started."), gdbinit);
 	       source_help_text, &cmdlist);
   set_cmd_completer (c, filename_completer);
 
+  add_setshow_enum_cmd ("script-extension", class_support,
+			script_ext_enums, &script_ext_mode, _("\
+Set mode for script filename extension recognition."), _("\
+Show mode for script filename extension recognition."), _("\
+off  == no filename extension recognition (all sourced files are GDB scripts)\n\
+soft == evaluate script according to filename extension, fallback to GDB script"
+  "\n\
+hard == evaluate script according to filename extension, error if not supported"
+  ),
+			NULL,
+			show_script_ext_mode,
+			&setlist, &showlist);
+
   add_com ("quit", class_support, quit_command, _("Exit gdb."));
   c = add_com ("help", class_support, help_command,
 	       _("Print list of commands."));
Index: gdb.git/gdb/doc/gdb.texinfo
===================================================================
--- gdb.git.orig/gdb/doc/gdb.texinfo	2009-06-01 00:51:11.000000000 -0300
+++ gdb.git/gdb/doc/gdb.texinfo	2009-06-01 00:52:37.000000000 -0300
@@ -957,8 +957,11 @@ Connect to process ID @var{number}, as w
 @itemx -x @var{file}
 @cindex @code{--command}
 @cindex @code{-x}
-Execute @value{GDBN} commands from file @var{file}.  @xref{Command
-Files,, Command files}.
+Execute commands from file @var{file}.  If @var{file} ends in
+@samp{.py}, then the file is evaluated as Python code.  If Python
+support is not enabled in this @value{GDBN}, then the file is assumed to
+contain @value{GDBN} commands, regardless of its extension.
+@xref{Command Files,, Command files}.
 
 @item -eval-command @var{command}
 @itemx -ex @var{command}
@@ -18227,6 +18230,11 @@ If @code{-v}, for verbose mode, is given
 each command as it is executed.  The option must be given before
 @var{filename}, and is interpreted as part of the filename anywhere else.
 
+If @var{filename} ends in @samp{.py}, then @value{GDBN} evaluates the
+contents of the file as Python code.  If Python support is not compiled
+in to @value{GDBN}, then the file is assumed to contain @value{GDBN}
+commands, regardless of its extension.
+
 Commands that would ask for confirmation if used interactively proceed
 without asking when used in a command file.  Many @value{GDBN} commands that
 normally print messages to say what they are doing omit the messages
Index: gdb.git/gdb/python/python.c
===================================================================
--- gdb.git.orig/gdb/python/python.c	2009-06-01 00:51:11.000000000 -0300
+++ gdb.git/gdb/python/python.c	2009-06-01 00:52:37.000000000 -0300
@@ -18,6 +18,7 @@
    along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
 #include "defs.h"
+#include "exceptions.h"
 #include "command.h"
 #include "ui-out.h"
 #include "cli/cli-script.h"
@@ -275,6 +276,22 @@ execute_gdb_command (PyObject *self, PyO
   Py_RETURN_NONE;
 }
 
+/* Read a file as Python code.  STREAM is the input file; FILE is the
+   name of the file.  */
+
+void
+source_python_script (FILE *stream, char *file)
+{
+  PyGILState_STATE state;
+
+  state = PyGILState_Ensure ();
+
+  PyRun_SimpleFile (stream, file);
+
+  fclose (stream);
+  PyGILState_Release (state);
+}
+
 \f
 
 /* Printing.  */
@@ -460,6 +477,14 @@ eval_python_from_control_command (struct
   error (_("Python scripting is not supported in this copy of GDB."));
 }
 
+void
+source_python_script (FILE *stream, char *file)
+{
+  fclose (stream);
+  throw_error (UNSUPPORTED_ERROR,
+	       _("Python scripting is not supported in this copy of GDB."));
+}
+
 #endif /* HAVE_PYTHON */
 
 \f
Index: gdb.git/gdb/python/python.h
===================================================================
--- gdb.git.orig/gdb/python/python.h	2009-06-01 00:51:12.000000000 -0300
+++ gdb.git/gdb/python/python.h	2009-06-01 00:53:48.000000000 -0300
@@ -26,6 +26,8 @@ extern struct value *values_in_python;
 
 void eval_python_from_control_command (struct command_line *);
 
+void source_python_script (FILE *stream, char *file);
+
 int apply_val_pretty_printer (struct type *type, const gdb_byte *valaddr,
 			      int embedded_offset, CORE_ADDR address,
 			      struct ui_file *stream, int recurse,
Index: gdb.git/gdb/testsuite/gdb.python/python.exp
===================================================================
--- gdb.git.orig/gdb/testsuite/gdb.python/python.exp	2009-06-01 00:52:37.000000000 -0300
+++ gdb.git/gdb/testsuite/gdb.python/python.exp	2009-06-01 00:55:50.000000000 -0300
@@ -27,8 +27,8 @@ gdb_start
 gdb_reinitialize_dir $srcdir/$subdir
 
 if ![python_supported] then {
-  unsupported "python support is disabled"
-  return -1
+  gdb_test "source $srcdir/$subdir/source2.py" "Error in sourced command file:.*"
+  return 0
 }
 
 gdb_py_test_multiple "multi-line python command" \
@@ -51,5 +51,7 @@ gdb_py_test_multiple "indented multi-lin
   "foo ()" "" \
   "end" "hello, world!"
 
+gdb_test "source $srcdir/$subdir/source2.py" "yes"
+
 gdb_test "python print gdb.current_objfile()" "None"
 gdb_test "python print gdb.objfiles()" "\\\[\\\]"
Index: gdb.git/gdb/testsuite/gdb.python/source1
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ gdb.git/gdb/testsuite/gdb.python/source1	2009-06-01 00:52:37.000000000 -0300
@@ -0,0 +1,19 @@
+#  This testcase is part of GDB, the GNU debugger.
+
+#  Copyright 2008, 2009 Free Software Foundation, Inc.
+
+#  This program is free software; you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 3 of the License, or
+#  (at your option) any later version.
+
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#  GNU General Public License for more details.
+
+#  You should have received a copy of the GNU General Public License
+#  along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# This is sourced as python; pick an expression that is not valid for gdb.
+print 'y%ss' % 'e'
Index: gdb.git/gdb/testsuite/gdb.python/source2.py
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ gdb.git/gdb/testsuite/gdb.python/source2.py	2009-06-01 00:52:37.000000000 -0300
@@ -0,0 +1,18 @@
+#  This testcase is part of GDB, the GNU debugger.
+
+#  Copyright 2008, 2009 Free Software Foundation, Inc.
+
+#  This program is free software; you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 3 of the License, or
+#  (at your option) any later version.
+
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#  GNU General Public License for more details.
+
+#  You should have received a copy of the GNU General Public License
+#  along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+print 'y%ss' % 'e'
Index: gdb.git/gdb/exceptions.h
===================================================================
--- gdb.git.orig/gdb/exceptions.h	2009-06-01 00:51:12.000000000 -0300
+++ gdb.git/gdb/exceptions.h	2009-06-01 00:52:37.000000000 -0300
@@ -75,6 +75,9 @@ enum errors {
   /* Error accessing memory.  */
   MEMORY_ERROR,
 
+  /* Feature is not supported in this copy of GDB.  */
+  UNSUPPORTED_ERROR,
+
   /* Add more errors here.  */
   NR_ERRORS
 };

Re: RFC: add ability to "source" Python code

[Paul Pluzhnikov]

On Sun, May 31, 2009 at 8:56 PM, Thiago Jung Bauermann
<bauerman@br.ibm.com> wrote:

> Set mode for script filename extension recognition.
> off  == no filename extension recognition (all sourced files are GDB scripts)
> soft == evaluate script according to filename extension, fallback to GDB script
> hard == evaluate script according to filename extension, error if not supported

Would naming the mode 'off', 'auto' and 'on' be more consistent with
the other settings?

-- 
Paul Pluzhnikov

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Date: Sun, 31 May 2009 22:04:55 -0700
> From: Paul Pluzhnikov <ppluzhnikov@google.com>
> Cc: Joel Brobecker <brobecker@adacore.com>, Tom Tromey <tromey@redhat.com>,         Eli Zaretskii <eliz@gnu.org>, drow@false.org, pedro@codesourcery.com,         gdb-patches@sourceware.org
> 
> Would naming the mode 'off', 'auto' and 'on' be more consistent with
> the other settings?

I don't think "auto" and "on" fit what they will do in this situation.

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> From: Thiago Jung Bauermann <bauerman@br.ibm.com>
> Cc: Tom Tromey <tromey@redhat.com>, Eli Zaretskii <eliz@gnu.org>,
>         drow@false.org, pedro@codesourcery.com, gdb-patches@sourceware.org
> Date: Mon, 01 Jun 2009 00:56:51 -0300
> 
> This patch implements such tri-state setting:
> 
> (gdb) help set script-extension
> Set mode for script filename extension recognition.
> off  == no filename extension recognition (all sourced files are GDB scripts)
> soft == evaluate script according to filename extension, fallback to GDB script
> hard == evaluate script according to filename extension, error if not supported
> 
> The default is 'soft'. When Python support is not compiled in, the code
> always assumes a GDB script.
> 
> Is this good enough for everybody?

Fine with me.

However, I would suggest "strict" instead of "hard".

Re: RFC: add ability to "source" Python code

[Thiago Jung Bauermann]

Em Seg, 2009-06-01 às 11:45 -0400, Eli Zaretskii escreveu:
> > Is this good enough for everybody?
> 
> Fine with me.

Awesome!

> However, I would suggest "strict" instead of "hard".

Sounds good. If others agree I'll make the change.

BTW I agree that "on" and "auto" don't fit very well.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: RFC: add ability to "source" Python code

[Tom Tromey]

>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> writes:

Thiago> This patch implements such tri-state setting:

Thiago> (gdb) help set script-extension
[...]

This patch is ok with the s/hard/strict/ change.  However, please give
people another week to object; someone may be at the Summit and miss
this thread.  Thanks for doing this.

Tom

Re: RFC: add ability to "source" Python code

[Joel Brobecker]

> Thiago> (gdb) help set script-extension
> [...]
> 
> This patch is ok with the s/hard/strict/ change.  However, please give
> people another week to object; someone may be at the Summit and miss
> this thread.  Thanks for doing this.

Looks great to me. Thanks Thiago!

-- 
Joel

Re: RFC: add ability to "source" Python code

[Paul Pluzhnikov]

On Wed, Jun 10, 2009 at 4:07 PM, Tom Tromey<tromey@redhat.com> wrote:

> This patch is ok with the s/hard/strict/ change.  However, please give
> people another week to object; someone may be at the Summit and miss
> this thread.  Thanks for doing this.

Three weeks have passed. Could we please get this in?
I am tired of typing "python execfile('whatever.py')" all the time.

Thanks, Thiago.
-- 
Paul Pluzhnikov

Re: RFC: add ability to "source" Python code

[Joel Brobecker]

> This patch implements such tri-state setting:
> 
> (gdb) help set script-extension
> Set mode for script filename extension recognition.
> off  == no filename extension recognition (all sourced files are GDB scripts)
> soft == evaluate script according to filename extension, fallback to GDB script
> hard == evaluate script according to filename extension, error if not supported
> 

> 2009-06-01  Tom Tromey  <tromey@redhat.com>
> 	    Thiago Jung Bauermann  <bauerman@br.ibm.com>
> 
> 	* python/python.c (source_python_script): New function.
> 	* python/python.h (source_python_script): Declare.
> 	* cli/cli-cmds.c (find_argument): New function.
> 	(source_command): Use find_argument.  Handle -p argument.  Use
> 	make_cleanup_restore_integer.
> 	(source_verbose_cleanup): Remove.
> 	(source_python): New global.
> 	Include python.h.
> 	(init_cli_cmds): Update.
> 
> 2009-06-01  Tom Tromey  <tromey@redhat.com>
> 
> 	* gdb.texinfo (File Options): Document -x on .py files.
> 	(Command Files): Document source -p.
> 
> 2009-06-01  Tom Tromey  <tromey@redhat.com>
> 	    Thiago Jung Bauermann  <bauerman@br.ibm.com>
> 
> 	* gdb.base/help.exp: Update "source" help text.
> 	* gdb.python/source2.py: New file.
> 	* gdb.python/source1: New file.
> 	* gdb.python/python.exp: Test "source" command.

This was approved a long time ago, with s/hard/strict/. Did we just
forget to apply it? I'm playing with python, right now, and it was
just brutal trying to find a way to "source" a file.

Refresher for those like me who are not completely fluent in Python.
It's:

    (gdb) python "execfile your-file.py"

-- 
Joel

Re: RFC: add ability to "source" Python code

[Joel Brobecker]

> This was approved a long time ago, with s/hard/strict/. Did we just
> forget to apply it? I'm playing with python, right now, and it was
> just brutal trying to find a way to "source" a file.

BTW: I would happy to rebase the code and commit, if that helps.

-- 
Joel

Re: RFC: add ability to "source" Python code

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

>> This was approved a long time ago, with s/hard/strict/. Did we just
>> forget to apply it? I'm playing with python, right now, and it was
>> just brutal trying to find a way to "source" a file.

Joel> BTW: I would happy to rebase the code and commit, if that helps.

Go for it.

Tom

Re: RFC: add ability to "source" Python code

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 109 bytes --]

Hello,

Attached is the patch that I ended up checking in.  I'll propose a NEWS
entry momentarily.

-- 
Joel

[-- Attachment #2: source-python.diff --]
[-- Type: text/x-diff, Size: 12006 bytes --]

commit 6a67114416d55f906d0b5aa05e11c3cfaa5b7adf
Author: Joel Brobecker <brobecker@adacore.com>
Date:   Mon Jan 18 09:54:28 2010 +0400

    Allow "source" to load python scripts.
    
    gdb/ChangeLog:
    
            Tom Tromey  <tromey@redhat.com>
            Thiago Jung Bauermann  <bauerman@br.ibm.com>
            * exceptions.h (enum errors): Add UNSUPPORTED_ERROR.
            * python/python.c (source_python_script): New function.
            * python/python.h (source_python_script): Add declaration.
            * cli/cli-cmds.c: #include exceptions.h and python/python.h.
            (script_ext_off, script_ext_soft, script_ext_strict)
            (script_ext_enums, script_ext_mode): New static constants.
            (show_script_ext_mode, find_and_open_script): New functions.
            (source_script): Enhance to handle Python scripts.
            (init_cli_cmds): Add set/show script-extension commands.
    
    gdb/doc/ChangeLog:
    
            Tom Tromey  <tromey@redhat.com>
            * gdb.texinfo (File Options): Document -x on .py files.
            (Command Files): Document handling of Python scripts.
    
    gdb/testsuite/ChangeLog:
    
            Tom Tromey  <tromey@redhat.com>
            Thiago Jung Bauermann  <bauerman@br.ibm.com>
            * gdb.python/source2.py: New file.
            * gdb.python/source1: New file.
            * gdb.python/python.exp: Test "source" command.

diff --git a/gdb/cli/cli-cmds.c b/gdb/cli/cli-cmds.c
index 4833898..7400967 100644
--- a/gdb/cli/cli-cmds.c
+++ b/gdb/cli/cli-cmds.c
@@ -19,6 +19,7 @@
    along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
 
 #include "defs.h"
+#include "exceptions.h"
 #include "arch-utils.h"
 #include "readline/readline.h"
 #include "readline/tilde.h"
@@ -47,6 +48,8 @@ extern void disconnect_or_stop_tracing (int from_tty);
 #include "cli/cli-setshow.h"
 #include "cli/cli-cmds.h"
 
+#include "python/python.h"
+
 #ifdef TUI
 #include "tui/tui.h"		/* For tui_active et.al.   */
 #endif
@@ -187,6 +190,21 @@ struct cmd_list_element *showchecklist;
 int source_verbose = 0;
 int trace_commands = 0;
 \f
+/* 'script-extension' option support.  */
+
+static const char script_ext_off[] = "off";
+static const char script_ext_soft[] = "soft";
+static const char script_ext_strict[] = "strict";
+
+static const char *script_ext_enums[] = {
+  script_ext_off,
+  script_ext_soft,
+  script_ext_strict,
+  NULL
+};
+
+static const char *script_ext_mode = script_ext_soft;
+\f
 /* Utility used everywhere when at least one argument is needed and
    none is supplied. */
 
@@ -441,18 +459,25 @@ cd_command (char *dir, int from_tty)
     pwd_command ((char *) 0, 1);
 }
 \f
-void
-source_script (char *file, int from_tty)
+/* Show the current value of the 'script-extension' option.  */
+
+static void
+show_script_ext_mode (struct ui_file *file, int from_tty,
+		     struct cmd_list_element *c, const char *value)
 {
-  FILE *stream;
-  struct cleanup *old_cleanups;
+  fprintf_filtered (file, _("\
+Script filename extension recognition is \"%s\".\n"),
+		    value);
+}
+
+static int
+find_and_open_script (int from_tty, char **filep, FILE **streamp,
+		      struct cleanup **cleanupp)
+{
+  char *file = *filep;
   char *full_pathname = NULL;
   int fd;
-
-  if (file == NULL || *file == 0)
-    {
-      error (_("source command requires file name of file to source."));
-    }
+  struct cleanup *old_cleanups;
 
   file = tilde_expand (file);
   old_cleanups = make_cleanup (xfree, file);
@@ -476,12 +501,58 @@ source_script (char *file, int from_tty)
       else
 	{
 	  do_cleanups (old_cleanups);
-	  return;
+	  return 0;
 	}
     }
 
-  stream = fdopen (fd, FOPEN_RT);
-  script_from_file (stream, file);
+  *streamp = fdopen (fd, FOPEN_RT);
+  *filep = file;
+  *cleanupp = old_cleanups;
+
+  return 1;
+}
+
+void
+source_script (char *file, int from_tty)
+{
+  FILE *stream;
+  struct cleanup *old_cleanups;
+
+  if (file == NULL || *file == 0)
+    {
+      error (_("source command requires file name of file to source."));
+    }
+
+  if (!find_and_open_script (from_tty, &file, &stream, &old_cleanups))
+    return;
+
+  if (script_ext_mode != script_ext_off
+      && strlen (file) > 3 && !strcmp (&file[strlen (file) - 3], ".py"))
+    {
+      volatile struct gdb_exception e;
+
+      TRY_CATCH (e, RETURN_MASK_ERROR)
+	{
+	  source_python_script (stream, file);
+	}
+      if (e.reason < 0)
+	{
+	  /* Should we fallback to ye olde GDB script mode?  */
+	  if (script_ext_mode == script_ext_soft
+	      && e.reason == RETURN_ERROR && e.error == UNSUPPORTED_ERROR)
+	    {
+	      if (!find_and_open_script (from_tty, &file, &stream, &old_cleanups))
+		return;
+
+	      script_from_file (stream, file);
+	    }
+	  else
+	    /* Nope, just punt.  */
+	    throw_exception (e);
+	}
+    }
+  else
+    script_from_file (stream, file);
 
   do_cleanups (old_cleanups);
 }
@@ -1314,6 +1385,19 @@ when GDB is started."), gdbinit);
 	       source_help_text, &cmdlist);
   set_cmd_completer (c, filename_completer);
 
+  add_setshow_enum_cmd ("script-extension", class_support,
+			script_ext_enums, &script_ext_mode, _("\
+Set mode for script filename extension recognition."), _("\
+Show mode for script filename extension recognition."), _("\
+off  == no filename extension recognition (all sourced files are GDB scripts)\n\
+soft == evaluate script according to filename extension, fallback to GDB script"
+  "\n\
+strict == evaluate script according to filename extension, error if not supported"
+  ),
+			NULL,
+			show_script_ext_mode,
+			&setlist, &showlist);
+
   add_com ("quit", class_support, quit_command, _("Exit gdb."));
   c = add_com ("help", class_support, help_command,
 	       _("Print list of commands."));
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 7cf1bb4..d37712b 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -963,8 +963,11 @@ Connect to process ID @var{number}, as with the @code{attach} command.
 @itemx -x @var{file}
 @cindex @code{--command}
 @cindex @code{-x}
-Execute @value{GDBN} commands from file @var{file}.  @xref{Command
-Files,, Command files}.
+Execute commands from file @var{file}.  If @var{file} ends in
+@samp{.py}, then the file is evaluated as Python code.  If Python
+support is not enabled in this @value{GDBN}, then the file is assumed to
+contain @value{GDBN} commands, regardless of its extension.
+@xref{Command Files,, Command files}.
 
 @item -eval-command @var{command}
 @itemx -ex @var{command}
@@ -19159,6 +19162,11 @@ If @code{-v}, for verbose mode, is given then @value{GDBN} displays
 each command as it is executed.  The option must be given before
 @var{filename}, and is interpreted as part of the filename anywhere else.
 
+If @var{filename} ends in @samp{.py}, then @value{GDBN} evaluates the
+contents of the file as Python code.  If Python support is not compiled
+in to @value{GDBN}, then the file is assumed to contain @value{GDBN}
+commands, regardless of its extension.
+
 Commands that would ask for confirmation if used interactively proceed
 without asking when used in a command file.  Many @value{GDBN} commands that
 normally print messages to say what they are doing omit the messages
diff --git a/gdb/exceptions.h b/gdb/exceptions.h
index 84a9f01..6b3cbeb 100644
--- a/gdb/exceptions.h
+++ b/gdb/exceptions.h
@@ -75,6 +75,9 @@ enum errors {
   /* Error accessing memory.  */
   MEMORY_ERROR,
 
+  /* Feature is not supported in this copy of GDB.  */
+  UNSUPPORTED_ERROR,
+
   /* Add more errors here.  */
   NR_ERRORS
 };
diff --git a/gdb/python/python.c b/gdb/python/python.c
index 827372c..1f1ae72 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -343,6 +343,22 @@ gdbpy_parse_and_eval (PyObject *self, PyObject *args)
   return value_to_value_object (result);
 }
 
+/* Read a file as Python code.  STREAM is the input file; FILE is the
+   name of the file.  */
+
+void
+source_python_script (FILE *stream, char *file)
+{
+  PyGILState_STATE state;
+
+  state = PyGILState_Ensure ();
+
+  PyRun_SimpleFile (stream, file);
+
+  fclose (stream);
+  PyGILState_Release (state);
+}
+
 \f
 
 /* Printing.  */
@@ -525,6 +541,14 @@ eval_python_from_control_command (struct command_line *cmd)
   error (_("Python scripting is not supported in this copy of GDB."));
 }
 
+void
+source_python_script (FILE *stream, char *file)
+{
+  fclose (stream);
+  throw_error (UNSUPPORTED_ERROR,
+	       _("Python scripting is not supported in this copy of GDB."));
+}
+
 #endif /* HAVE_PYTHON */
 
 \f
diff --git a/gdb/python/python.h b/gdb/python/python.h
index f35827b..5d93f67 100644
--- a/gdb/python/python.h
+++ b/gdb/python/python.h
@@ -24,6 +24,8 @@
 
 void eval_python_from_control_command (struct command_line *);
 
+void source_python_script (FILE *stream, char *file);
+
 int apply_val_pretty_printer (struct type *type, const gdb_byte *valaddr,
 			      int embedded_offset, CORE_ADDR address,
 			      struct ui_file *stream, int recurse,
diff --git a/gdb/testsuite/gdb.python/python.exp b/gdb/testsuite/gdb.python/python.exp
index 951c295..b345ad2 100644
--- a/gdb/testsuite/gdb.python/python.exp
+++ b/gdb/testsuite/gdb.python/python.exp
@@ -29,6 +29,10 @@ gdb_reinitialize_dir $srcdir/$subdir
 gdb_test_multiple "python print 23" "verify python support" {
     -re "not supported.*$gdb_prompt $"	{
       unsupported "python support is disabled"
+
+      # If Python is not supported, verify that sourcing a python script
+      # causes an error.
+      gdb_test "source $srcdir/$subdir/source2.py" "Error in sourced command file:.*"
       return -1
     }
     -re "$gdb_prompt $"	{}
@@ -72,5 +76,7 @@ gdb_py_test_multiple "indented multi-line python command" \
   "foo ()" "" \
   "end" "hello, world!"
 
+gdb_test "source $srcdir/$subdir/source2.py" "yes"
+
 gdb_test "python print gdb.current_objfile()" "None"
 gdb_test "python print gdb.objfiles()" "\\\[\\\]"
diff --git a/gdb/testsuite/gdb.python/source1 b/gdb/testsuite/gdb.python/source1
new file mode 100644
index 0000000..f9c19bd
--- /dev/null
+++ b/gdb/testsuite/gdb.python/source1
@@ -0,0 +1,19 @@
+#  This testcase is part of GDB, the GNU debugger.
+
+#  Copyright 2008, 2009, 2010 Free Software Foundation, Inc.
+
+#  This program is free software; you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 3 of the License, or
+#  (at your option) any later version.
+
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#  GNU General Public License for more details.
+
+#  You should have received a copy of the GNU General Public License
+#  along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# This is sourced as python; pick an expression that is not valid for gdb.
+print 'y%ss' % 'e'
diff --git a/gdb/testsuite/gdb.python/source2.py b/gdb/testsuite/gdb.python/source2.py
new file mode 100644
index 0000000..4e9a9e3
--- /dev/null
+++ b/gdb/testsuite/gdb.python/source2.py
@@ -0,0 +1,18 @@
+#  This testcase is part of GDB, the GNU debugger.
+
+#  Copyright 2008, 2009, 2010 Free Software Foundation, Inc.
+
+#  This program is free software; you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 3 of the License, or
+#  (at your option) any later version.
+
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#  GNU General Public License for more details.
+
+#  You should have received a copy of the GNU General Public License
+#  along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+print 'y%ss' % 'e'

Re: RFC: add ability to "source" Python code

[Eli Zaretskii]

> Date: Mon, 18 Jan 2010 10:33:03 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>, 	Eli Zaretskii <eliz@gnu.org>, drow@false.org, 	pedro@codesourcery.com, gdb-patches@sourceware.org
> 
>     gdb/doc/ChangeLog:
>     
>             Tom Tromey  <tromey@redhat.com>
>             * gdb.texinfo (File Options): Document -x on .py files.
>             (Command Files): Document handling of Python scripts.

Okay for this part, except that:

> +contents of the file as Python code.  If Python support is not compiled
> +in to @value{GDBN}, then the file is assumed to contain @value{GDBN}
   ^^^^^
"into"

Thanks.

Re: RFC: add ability to "source" Python code

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

> >     gdb/doc/ChangeLog:
> >     
> >             Tom Tromey  <tromey@redhat.com>
> >             * gdb.texinfo (File Options): Document -x on .py files.
> >             (Command Files): Document handling of Python scripts.
> 
> Okay for this part, except that:

Ooops, sorry - I was confused as to the status of the documentation.
Somehow, I managed to understand that your approval of the change
included the approval of the documentation update. I apologize.

I checked in this patch, to fix the issue you spotted.

2010-01-19  Joel Brobecker  <brobecker@adacore.com>

        * gdb.texinfo (Command Files): Fix typo.

-- 
Joel

[-- Attachment #2: gdb.texinfo.diff --]
[-- Type: text/x-diff, Size: 745 bytes --]

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.660
diff -u -p -r1.660 gdb.texinfo
--- gdb.texinfo	18 Jan 2010 06:28:47 -0000	1.660
+++ gdb.texinfo	19 Jan 2010 10:27:39 -0000
@@ -19164,7 +19164,7 @@ each command as it is executed.  The opt
 
 If @var{filename} ends in @samp{.py}, then @value{GDBN} evaluates the
 contents of the file as Python code.  If Python support is not compiled
-in to @value{GDBN}, then the file is assumed to contain @value{GDBN}
+into @value{GDBN}, then the file is assumed to contain @value{GDBN}
 commands, regardless of its extension.
 
 Commands that would ask for confirmation if used interactively proceed