RFC: GDB as a loader 3/3: --eval-command option

RFC: GDB as a loader 3/3: --eval-command option

[Andrew STUBBS]

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

Hi all,

The attached patch implements a new option --eval-command (-ex for
short) which works similarly to the --command option except that it
passes the command itself, rather than a file name containing commands.

In most cases, this eliminates the need for temporary files or messing 
around with stdin when running programs via the debugger.

For example:

gdb hello.exe --batch -ex 'target sim' -ex load -ex run

This option may be used in conjunction with the existing --command (-x)
command and the order of the options is honoured.

It is still necessary to use a script file if define/if/while, or any
other nested construct, is required. Suggestions on how to deal with
this would be welcome.

Note that the patch assumes that the batch-silent and
return-child-result patches have already been applied (although the
implementation in no way depends on those features).

Thanks

Andrew Stubbs



[-- Attachment #2: eval-command.patch --]
[-- Type: text/plain, Size: 3536 bytes --]

2005-10-18  Andrew Stubbs  <andrew.stubbs@st.com>

	* main.c (captured_main): Define struct cmdarg. Change type of cmdarg.
	Add new options --eval-command and alias -ex.
	Adjust --command to use the new struct cmdarg.
	Execute commands given with --eval-command.
	(print_gdb_help): Add new options --eval-command, -ex and mention -x.


Index: src/gdb/main.c
===================================================================
--- src.orig/gdb/main.c	2005-10-18 09:57:29.000000000 +0100
+++ src/gdb/main.c	2005-10-18 10:14:27.000000000 +0100
@@ -138,7 +138,13 @@ captured_main (void *data)
   static int print_version;
 
   /* Pointers to all arguments of --command option.  */
-  char **cmdarg;
+  struct cmdarg {
+    enum {
+      CMDARG_FILE,
+      CMDARG_COMMAND
+    } type;
+    char *string;
+  } *cmdarg;
   /* Allocated size of cmdarg.  */
   int cmdsize;
   /* Number of elements of cmdarg used.  */
@@ -178,7 +184,7 @@ captured_main (void *data)
 #endif
 
   cmdsize = 1;
-  cmdarg = (char **) xmalloc (cmdsize * sizeof (*cmdarg));
+  cmdarg = (struct cmdarg *) xmalloc (cmdsize * sizeof (*cmdarg));
   ncmd = 0;
   dirsize = 1;
   dirarg = (char **) xmalloc (dirsize * sizeof (*dirarg));
@@ -285,8 +291,10 @@ captured_main (void *data)
       {"pid", required_argument, 0, 'p'},
       {"p", required_argument, 0, 'p'},
       {"command", required_argument, 0, 'x'},
+      {"eval-command", required_argument, 0, 'X'},
       {"version", no_argument, &print_version, 1},
       {"x", required_argument, 0, 'x'},
+      {"ex", required_argument, 0, 'X'},
 #ifdef GDBTK
       {"tclcommand", required_argument, 0, 'z'},
       {"enable-external-editor", no_argument, 0, 'y'},
@@ -387,12 +395,23 @@ captured_main (void *data)
 	    corearg = optarg;
 	    break;
 	  case 'x':
-	    cmdarg[ncmd++] = optarg;
+	    cmdarg[ncmd].type = CMDARG_FILE;
+	    cmdarg[ncmd++].string = optarg;
+	    if (ncmd >= cmdsize)
+	      {
+		cmdsize *= 2;
+		cmdarg = xrealloc ((char *) cmdarg,
+				   cmdsize * sizeof (*cmdarg));
+	      }
+	    break;
+	  case 'X':
+	    cmdarg[ncmd].type = CMDARG_COMMAND;
+	    cmdarg[ncmd++].string = optarg;
 	    if (ncmd >= cmdsize)
 	      {
 		cmdsize *= 2;
-		cmdarg = (char **) xrealloc ((char *) cmdarg,
-					     cmdsize * sizeof (*cmdarg));
+		cmdarg = xrealloc ((char *) cmdarg,
+				   cmdsize * sizeof (*cmdarg));
 	      }
 	    break;
 	  case 'B':
@@ -733,7 +752,12 @@ extern int gdbtk_test (char *);
 	  do_cleanups (ALL_CLEANUPS);
 	}
 #endif
-      catch_command_errors (source_command, cmdarg[i], !batch, RETURN_MASK_ALL);
+      if (cmdarg[i].type == CMDARG_FILE)
+        catch_command_errors (source_command, cmdarg[i].string,
+			      !batch, RETURN_MASK_ALL);
+      else  /* cmdarg[i].type == CMDARG_COMMAND */
+        catch_command_errors (execute_command, cmdarg[i].string,
+			      !batch, RETURN_MASK_ALL);
     }
   xfree (cmdarg);
 
@@ -846,7 +870,11 @@ Options:\n\n\
   --return-child-result\n\
                      GDB exit code will be the child's exit code.\n\
   --cd=DIR           Change current directory to DIR.\n\
-  --command=FILE     Execute GDB commands from FILE.\n\
+  --command=FILE, -x Execute GDB commands from FILE.\n\
+  --eval-command=COMMAND, -ex\n\
+                     Execute a single GDB command.\n\
+                     May be used multiple times and in conjunction\n\
+                     with --command.\n\
   --core=COREFILE    Analyze the core dump COREFILE.\n\
   --pid=PID          Attach to running process PID.\n\
 "), stream);

Re: RFC: GDB as a loader 3/3: --eval-command option

[Andrew STUBBS]

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

Here is a documentation patch for the --eval-command option.

I am not sure this is the right place in the manual. It is not a 'file' 
option as such, but nor is it a 'mode' option, and I want to put it 
alongside -command.

Andrew Stubbs

[-- Attachment #2: eval-command-docs.patch --]
[-- Type: text/plain, Size: 965 bytes --]

2005-10-28  Andrew Stubbs  <andrew.stubbs@st.com>

	* gdb.texinfo (Choosing files): Add --eval-command.


Index: src/gdb/doc/gdb.texinfo
===================================================================
--- src.orig/gdb/doc/gdb.texinfo	2005-10-28 11:35:18.000000000 +0100
+++ src/gdb/doc/gdb.texinfo	2005-10-28 11:59:02.000000000 +0100
@@ -932,6 +932,19 @@ file named @var{number}.
 Execute @value{GDBN} commands from file @var{file}.  @xref{Command
 Files,, Command files}.
 
+@item -eval-command @var{command}
+@itemx -ex @var{command}
+@cindex @code{--eval-command}
+@cindex @code{-ex}
+Execute a single @value{GDBN} command.
+
+This option may be used multiple times to call multiple commands. It may
+also be interleaved with @samp{-command} as required.
+
+@smallexample
+@value{GDBP} -ex 'target sim' -ex 'load' -x setbreakpoints -ex 'run' a.out
+@end smallexample
+
 @item -directory @var{directory}
 @itemx -d @var{directory}
 @cindex @code{--directory}

Re: RFC: GDB as a loader 3/3: --eval-command option

[Eli Zaretskii]

> Date: Fri, 28 Oct 2005 12:08:02 +0100
> From: Andrew STUBBS <andrew.stubbs@st.com>
> 
> Here is a documentation patch for the --eval-command option.

Thanks.

> I am not sure this is the right place in the manual. It is not a 'file' 
> option as such, but nor is it a 'mode' option, and I want to put it 
> alongside -command.

That is fine.

> +This option may be used multiple times to call multiple commands. It may
                                                                   ^^
Need two spaces here.

> +@smallexample
> +@value{GDBP} -ex 'target sim' -ex 'load' -x setbreakpoints -ex 'run' a.out
> +@end smallexample

Please make the example shorter, because this is too long and will
overflow the page margins.  (Alternatively, break the command into two
lines, and put a `\' at the end of the first one, as you'd do at the
shell's prompt.)

Re: RFC: GDB as a loader 3/3: --eval-command option

[Andrew STUBBS]

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

> Please make the example shorter, because this is too long and will
> overflow the page margins.  (Alternatively, break the command into two
> lines, and put a `\' at the end of the first one, as you'd do at the
> shell's prompt.)
> 

I've wrapped it. What is the proper width? It fitted into 80 columns ok 
so I thought it would be fine.

Andrew

[-- Attachment #2: eval-command-docs.patch --]
[-- Type: text/plain, Size: 972 bytes --]

2005-10-28  Andrew Stubbs  <andrew.stubbs@st.com>

	* gdb.texinfo (Choosing files): Add --eval-command.


Index: src/gdb/doc/gdb.texinfo
===================================================================
--- src.orig/gdb/doc/gdb.texinfo	2005-10-28 14:39:29.000000000 +0100
+++ src/gdb/doc/gdb.texinfo	2005-10-28 14:43:37.000000000 +0100
@@ -932,6 +932,20 @@ file named @var{number}.
 Execute @value{GDBN} commands from file @var{file}.  @xref{Command
 Files,, Command files}.
 
+@item -eval-command @var{command}
+@itemx -ex @var{command}
+@cindex @code{--eval-command}
+@cindex @code{-ex}
+Execute a single @value{GDBN} command.
+
+This option may be used multiple times to call multiple commands.  It may
+also be interleaved with @samp{-command} as required.
+
+@smallexample
+@value{GDBP} -ex 'target sim' -ex 'load' \
+   -x setbreakpoints -ex 'run' a.out
+@end smallexample
+
 @item -directory @var{directory}
 @itemx -d @var{directory}
 @cindex @code{--directory}

Re: RFC: GDB as a loader 3/3: --eval-command option

[Eli Zaretskii]

> Date: Fri, 28 Oct 2005 14:59:16 +0100
> From: Andrew STUBBS <andrew.stubbs@st.com>
> Cc: gdb@sources.redhat.com
> 
> > Please make the example shorter, because this is too long and will
> > overflow the page margins.  (Alternatively, break the command into two
> > lines, and put a `\' at the end of the first one, as you'd do at the
> > shell's prompt.)
> 
> I've wrapped it.

Thanks.

> What is the proper width?

With the fonts we use in the printed version of the manual, IIRC
anything wider than 65 columns might overflow the margins.  The
typesetter doesn't break lines in @example and @smallexample blocks.

Re: RFC: GDB as a loader 3/3: --eval-command option

[Andrew STUBBS]

Andrew Stubbs wrote:
> Hi all,
> 
> The attached patch implements a new option --eval-command (-ex for
> short) which works similarly to the --command option except that it
> passes the command itself, rather than a file name containing commands.

May I commit this and the doc patch, please?

Andrew Stubbs

Re: RFC: GDB as a loader 3/3: --eval-command option

[Daniel Jacobowitz]

On Fri, Nov 04, 2005 at 11:52:39AM +0000, Andrew STUBBS wrote:
> Andrew Stubbs wrote:
> >Hi all,
> >
> >The attached patch implements a new option --eval-command (-ex for
> >short) which works similarly to the --command option except that it
> >passes the command itself, rather than a file name containing commands.
> 
> May I commit this and the doc patch, please?

The code patch is OK with me (wish I'd done this instead of messing
around with mktemp last month).  I believe Eli is OK with your revised
documentation, but please give him a chance to confirm that before you
commit.

Should this, or the others, be in NEWS?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: GDB as a loader 3/3: --eval-command option

[Eli Zaretskii]

> Date: Fri, 4 Nov 2005 21:50:59 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sources.redhat.com
> 
> I believe Eli is OK with your revised documentation, but please give
> him a chance to confirm that before you commit.

Yes, the final version of the doc patch in
http://sourceware.org/ml/gdb/2005-10/msg00187.html is okay with me.

> Should this, or the others, be in NEWS?

Good point.  Yes, I think all the new command-line options should be
mentioned in NEWS.  Andrew, could you please write that up and post
here for approval?

Re: RFC: GDB as a loader 3/3: --eval-command option

[Andrew STUBBS]

Eli Zaretskii wrote:
>>I believe Eli is OK with your revised documentation, but please give
>>him a chance to confirm that before you commit.
> 
> 
> Yes, the final version of the doc patch in
> http://sourceware.org/ml/gdb/2005-10/msg00187.html is okay with me.

Thanks. I have now committed this.

Andrew Stubbs

Re: RFC: GDB as a loader 3/3: --eval-command option

[Andrew STUBBS]

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

Eli Zaretskii wrote:
>>Should this, or the others, be in NEWS?
> 
> 
> Good point.  Yes, I think all the new command-line options should be
> mentioned in NEWS.  Andrew, could you please write that up and post
> here for approval?

On looking at the NEWS files more closely I am a little uncertain what 
to do about the mainline file. The attached patch should do fine for the 
6.4 branch however (I don't think this needs any more, does it?).

The mainline does not contain anything about 6.4 yet. Presumably this 
will be merged across when the 6.4 stuff is completed?

Should I add a 6.5 section for my changes?

Andrew Stubbs

[-- Attachment #2: 6.4-news.patch --]
[-- Type: text/plain, Size: 473 bytes --]

2005-11-07  Andrew Stubbs  <andrew.stubbs@st.com>

	* NEWS: Add --batch-silent option.

--- src6.4.orig/NEWS	2005-11-07 14:12:02.000000000 +0000
+++ src6.4/NEWS	2005-11-07 14:12:08.000000000 +0000
@@ -12,6 +12,10 @@ OpenBSD/mips64			mips64-*-openbsd*
 
 Morpho Technologies ms1		ms1-elf
 
+* New command line options
+
+--batch-silent			As for --batch, but totally silent.
+
 * Deprecated commands removed
 
 The following commands, that were deprecated in 2000, have been

Re: RFC: GDB as a loader 3/3: --eval-command option

[Joel Brobecker]

> On looking at the NEWS files more closely I am a little uncertain what 
> to do about the mainline file. The attached patch should do fine for the 
> 6.4 branch however (I don't think this needs any more, does it?).
> 
> The mainline does not contain anything about 6.4 yet. Presumably this 
> will be merged across when the 6.4 stuff is completed?
> 
> Should I add a 6.5 section for my changes?

Indeed, I think you need to add a new section like this:

*** Changes since GDB 6.4

-- 
Joel

Re: RFC: GDB as a loader 3/3: --eval-command option

[Andrew STUBBS]

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

Joel Brobecker wrote:
> Indeed, I think you need to add a new section like this:
> 
> *** Changes since GDB 6.4

OK, how about the attached? There's one for the branch and one for mainline.

I added the new stuff above the deprecated stuff rather than just 
appeanding it to the end.

Andrew Stubbs

[-- Attachment #2: main-news.patch --]
[-- Type: text/plain, Size: 1212 bytes --]

2005-11-07  Andrew Stubbs  <andrew.stubbs@st.com>

	* NEWS: Change 'since 6.3' to 'in 6.4' and add --batch-silent option.
	Add 'since 6.4' section with --return-child-result and --eval-command
	options.

Index: src/gdb/NEWS
===================================================================
--- src.orig/gdb/NEWS	2005-11-07 17:37:18.000000000 +0000
+++ src/gdb/NEWS	2005-11-07 17:45:23.000000000 +0000
@@ -1,7 +1,18 @@
 		What has changed in GDB?
 	     (Organized release by release)
 
-*** Changes since GDB 6.3
+*** Changes since GDB 6.4
+
+* New command line options
+
+--return-child-result		The debugger will exist with the same value
+				the child (debugged) program exited with.
+--eval-command COMMAND, -ex COMMAND
+				Execute a single GDB CLI command. This may be
+				specified multiple times and in conjunction
+				with the --command (-x) option.
+
+*** Changes in GDB 6.4
 
 * New native configurations
 
@@ -12,6 +23,10 @@ OpenBSD/mips64			mips64-*-openbsd*
 
 Morpho Technologies ms1		ms1-elf
 
+* New command line options
+
+--batch-silent                 As for --batch, but totally silent.
+
 * Deprecated commands removed
 
 The following commands, that were deprecated in 2000, have been

[-- Attachment #3: 6.4-news.patch --]
[-- Type: text/plain, Size: 560 bytes --]

2005-11-07  Andrew Stubbs  <andrew.stubbs@st.com>

	* NEWS: Add --batch-silent option.

Index: src6.4/NEWS
===================================================================
--- src6.4.orig/NEWS	2005-11-07 14:12:02.000000000 +0000
+++ src6.4/NEWS	2005-11-07 14:12:08.000000000 +0000
@@ -12,6 +12,10 @@ OpenBSD/mips64			mips64-*-openbsd*
 
 Morpho Technologies ms1		ms1-elf
 
+* New command line options
+
+--batch-silent			As for --batch, but totally silent.
+
 * Deprecated commands removed
 
 The following commands, that were deprecated in 2000, have been

Re: RFC: GDB as a loader 3/3: --eval-command option

[Eli Zaretskii]

> Date: Mon, 07 Nov 2005 14:13:32 +0000
> From: Andrew STUBBS <andrew.stubbs@st.com>
> Cc: gdb@sources.redhat.com
> 
> On looking at the NEWS files more closely I am a little uncertain what 
> to do about the mainline file. The attached patch should do fine for the 
> 6.4 branch however (I don't think this needs any more, does it?).

It's fine.

> The mainline does not contain anything about 6.4 yet. Presumably this 
> will be merged across when the 6.4 stuff is completed?

Any patches that are committed to the branch and mainline, should be
mentioned in mainline's NEWS as well.

> Should I add a 6.5 section for my changes?

Only if we decide not to commit them to the branch as well.
Personally, I don't see why not have them in 6.4, they cannot possibly
harm anything.

Re: RFC: GDB as a loader 3/3: --eval-command option

[Eli Zaretskii]

> Date: Mon, 07 Nov 2005 18:03:44 +0000
> From: Andrew STUBBS <andrew.stubbs@st.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sources.redhat.com
> 
> Joel Brobecker wrote:
> > Indeed, I think you need to add a new section like this:
> > 
> > *** Changes since GDB 6.4
> 
> OK, how about the attached? There's one for the branch and one for mainline.

Fine with me.  Thanks.

Re: RFC: GDB as a loader 3/3: --eval-command option

[Andrew STUBBS]

Eli Zaretskii wrote:
>>Should I add a 6.5 section for my changes?
> 
> 
> Only if we decide not to commit them to the branch as well.
> Personally, I don't see why not have them in 6.4, they cannot possibly
> harm anything.

Anybody object to my putting --return-child-result (including the header 
file update) and --eval-command into 6.4?

Anybody else in favour?

Andrew

Re: RFC: GDB as a loader 3/3: --eval-command option

[Daniel Jacobowitz]

On Tue, Nov 08, 2005 at 11:02:07AM +0000, Andrew STUBBS wrote:
> Eli Zaretskii wrote:
> >>Should I add a 6.5 section for my changes?
> >
> >
> >Only if we decide not to commit them to the branch as well.
> >Personally, I don't see why not have them in 6.4, they cannot possibly
> >harm anything.
> 
> Anybody object to my putting --return-child-result (including the header 
> file update) and --eval-command into 6.4?
> 
> Anybody else in favour?

Sounds reasonable to me.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: RFC: GDB as a loader 3/3: --eval-command option

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> On Tue, Nov 08, 2005 at 11:02:07AM +0000, Andrew STUBBS wrote:
> 
>>Eli Zaretskii wrote:
>>
>>>>Should I add a 6.5 section for my changes?
>>>
>>>
>>>Only if we decide not to commit them to the branch as well.
>>>Personally, I don't see why not have them in 6.4, they cannot possibly
>>>harm anything.
>>
>>Anybody object to my putting --return-child-result (including the header 
>>file update) and --eval-command into 6.4?
>>
>>Anybody else in favour?
> 
> 
> Sounds reasonable to me.
> 

Is that an 'OK, go ahead', or just part of the discussion?

Re: RFC: GDB as a loader 3/3: --eval-command option

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> Please go ahead.

Thanks, done.

Andrew Stubbs