[RFC] 09/10 Add "continue --all"

[RFC] 09/10 Add "continue --all"

[Pedro Alves]

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

In non-stop mode, exec commands apply only to the current thread.
We can add a mechanism to resume all threads.  In a frontend
perpective, I'm not clear if we should implement
-exec-continue --all, -exec-continue --thread="all", or just
require the frontend to do the:

for each thread in stopped threads
  resume thread
done

In CLI,  "thread apply all continue&" works too, but it feels
to longuish to type?

Opinions?  Import mi-getopt into common code and use it in CLI?

-- 
Pedro Alves

[-- Attachment #2: 009-continue_all.diff --]
[-- Type: text/x-diff, Size: 4245 bytes --]

2008-05-06  Pedro Alves  <pedro@codesourcery.com>

	* infcmd.c (proceed_thread_callback, do_context_switch_to): New.
	(continue_command): In non-stop mode, if user passes "--all",
	resume all running threads.
	* inferior.h (proceed_ptid): Declare.
	* infrun.c (proceed_ptid): New.

---
 gdb/infcmd.c   |   59 +++++++++++++++++++++++++++++++++++++++++++++++++--------
 gdb/inferior.h |    2 +
 gdb/infrun.c   |    9 ++++++++
 3 files changed, 62 insertions(+), 8 deletions(-)

Index: src/gdb/infcmd.c
===================================================================
--- src.orig/gdb/infcmd.c	2008-05-06 12:15:51.000000000 +0100
+++ src/gdb/infcmd.c	2008-05-06 12:17:35.000000000 +0100
@@ -607,16 +607,37 @@ start_command (char *args, int from_tty)
   run_command_1 (args, from_tty, 1);
 } 
 
+static int
+proceed_thread_callback (struct thread_info *thread, void *arg)
+{
+  if (is_running (thread->ptid))
+    return 0;
+  if (thread == arg)
+    return 0;
+
+  proceed_ptid (thread->ptid);
+  return 0;
+}
+
+static void
+do_context_switch_to (void *arg)
+{
+  ptid_t *ptid = arg;
+  context_switch_to (*ptid);
+}
+
+/* continue [--all] [proceed count] [&]  */
 void
-continue_command (char *proc_count_exp, int from_tty)
+continue_command (char *args, int from_tty)
 {
   int async_exec = 0;
+  int all_threads = 0;
   ERROR_NO_INFERIOR;
   ensure_not_running ();
 
   /* Find out whether we must run in the background. */
-  if (proc_count_exp != NULL)
-    async_exec = strip_bg_char (&proc_count_exp);
+  if (args != NULL)
+    async_exec = strip_bg_char (&args);
 
   /* If we must run in the background, but the target can't do it,
      error out. */
@@ -631,9 +652,20 @@ continue_command (char *proc_count_exp, 
       async_disable_stdin ();
     }
 
+  if (args != NULL)
+    {
+      if (strncmp (args, "--all", 5) == 0)
+	{
+	  all_threads = 1;
+	  args += sizeof ("--all") - 1;
+	  if (*args == '\0')
+	    args = NULL;
+	}
+    }
+
   /* If have argument (besides '&'), set proceed count of breakpoint
      we stopped at.  */
-  if (proc_count_exp != NULL)
+  if (args != NULL)
     {
       bpstat bs = stop_bpstat;
       int num, stat;
@@ -643,7 +675,7 @@ continue_command (char *proc_count_exp, 
 	if (stat > 0)
 	  {
 	    set_ignore_count (num,
-			      parse_and_eval_long (proc_count_exp) - 1,
+			      parse_and_eval_long (args) - 1,
 			      from_tty);
 	    /* set_ignore_count prints a message ending with a period.
 	       So print two spaces before "Continuing.".  */
@@ -662,9 +694,20 @@ continue_command (char *proc_count_exp, 
   if (from_tty)
     printf_filtered (_("Continuing.\n"));
 
-  clear_proceed_status ();
-
-  proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 0);
+  if (non_stop && all_threads)
+    {
+      ptid_t current_ptid = inferior_ptid;
+      struct cleanup *old_chain
+	= make_cleanup (do_context_switch_to, &current_ptid);
+      iterate_over_threads (proceed_thread_callback, NULL);
+      /* Restore selected ptid.  */
+      do_cleanups (old_chain);
+    }
+  else
+    {
+      clear_proceed_status ();
+      proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 0);
+    }
 }
 \f
 /* Step until outside of current statement.  */
Index: src/gdb/inferior.h
===================================================================
--- src.orig/gdb/inferior.h	2008-05-06 12:15:51.000000000 +0100
+++ src/gdb/inferior.h	2008-05-06 12:15:55.000000000 +0100
@@ -132,6 +132,8 @@ extern void clear_proceed_status (void);
 
 extern void proceed (CORE_ADDR, enum target_signal, int);
 
+extern void proceed_ptid (ptid_t);
+
 extern ptid_t context_switch_to (ptid_t ptid);
 
 /* When set, stop the 'step' command if we enter a function which has
Index: src/gdb/infrun.c
===================================================================
--- src.orig/gdb/infrun.c	2008-05-06 12:15:51.000000000 +0100
+++ src/gdb/infrun.c	2008-05-06 12:15:55.000000000 +0100
@@ -1317,6 +1317,15 @@ proceed (CORE_ADDR addr, enum target_sig
       normal_stop ();
     }
 }
+
+/* Proceed thread PTID.  */
+void
+proceed_ptid (ptid_t ptid)
+{
+  context_switch_to (ptid);
+  clear_proceed_status ();
+  proceed ((CORE_ADDR) -1, TARGET_SIGNAL_0, 0);
+}
 \f
 
 /* Start remote-debugging of a machine over a serial link.  */

RE: [RFC] 09/10 Add "continue --all"

[Pierre Muller]

 I don't claim to understand this patch,
but I am still curious about one point:

why do you use TARGET_SIGNAL_0
in proceed_ptid,
while in non-stop mode, TARGET_SIGNAL_DEFAULT is used.

 If I understood correctly the code in 
proceed function from infrun.c,
this would mean that in the non-stop mode with --all option,
even if stop_signal was set to a value
that is registered as "PASS",
stop_signal would be reset and
not passed to the inferior.

  
  Isn't that a misbehavior?

  But anyway, should stop_signal become
a threadvar, in the sense that it should
be saved and restore in context_switch?


Pierre Muller
Pascal language support maintainer for GDB



-----Message d'origine-----
De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] De la part de Pedro Alves
Envoyé : Tuesday, May 06, 2008 5:50 PM
À : gdb-patches@sourceware.org
Objet : [RFC] 09/10 Add "continue --all"

In non-stop mode, exec commands apply only to the current thread.
We can add a mechanism to resume all threads.  In a frontend perpective, I'm not clear if we should implement -exec-continue --all, -exec-continue --thread="all", or just require the frontend to do the:

for each thread in stopped threads
  resume thread
done

In CLI,  "thread apply all continue&" works too, but it feels to longuish to type?

Opinions?  Import mi-getopt into common code and use it in CLI?

--
Pedro Alves

Re: [RFC] 09/10 Add "continue --all"

[Pedro Alves]

A Wednesday 07 May 2008 09:21:53, Pierre Muller wrote:
>  I don't claim to understand this patch,
> but I am still curious about one point:
>
> why do you use TARGET_SIGNAL_0
> in proceed_ptid,
> while in non-stop mode, TARGET_SIGNAL_DEFAULT is used.
>

Because I copy&pasted it from somewhere else, and
didn't notice that. :-)

>  If I understood correctly the code in
> proceed function from infrun.c,
> this would mean that in the non-stop mode with --all option,
> even if stop_signal was set to a value
> that is registered as "PASS",
> stop_signal would be reset and
> not passed to the inferior.
>
>
>   Isn't that a misbehavior?
>

Thanks!  That's indeed a bug.

>   But anyway, should stop_signal become
> a threadvar, in the sense that it should
> be saved and restore in context_switch?
>

That's right.  Not scritly command-per-thread related, but it
was taken care of in patch 4.

-- 
Pedro Alves

Re: [RFC] 09/10 Add "continue --all"

[Eli Zaretskii]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Tue, 6 May 2008 16:49:50 +0100
> 
> +  if (args != NULL)
> +    {
> +      if (strncmp (args, "--all", 5) == 0)

Can we please void literal constants like 5 here?  sizeof should be
our friend, and you actually use it 3 lines below this:

> +	{
> +	  all_threads = 1;
> +	  args += sizeof ("--all") - 1;
> +	  if (*args == '\0')
> +	    args = NULL;
> +	}

Re: [RFC] 09/10 Add "continue --all"

[Pedro Alves]

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

A Thursday 08 May 2008 12:42:51, Eli Zaretskii wrote:
> > From: Pedro Alves <pedro@codesourcery.com>
> > Date: Tue, 6 May 2008 16:49:50 +0100
> >
> > +  if (args != NULL)
> > +    {
> > +      if (strncmp (args, "--all", 5) == 0)
>
> Can we please void literal constants like 5 here?  sizeof should be
>
> our friend, and you actually use it 3 lines below this:
> > +	{
> > +	  all_threads = 1;
> > +	  args += sizeof ("--all") - 1;
> > +	  if (*args == '\0')
> > +	    args = NULL;
> > +	}

Oooops!

And after a bit, it hit me that we use /opt most everywhere
else, so "continue /a" makes more sense?

(gdb) help continue
Continue program being debugged, after signal or breakpoint.
If proceeding from breakpoint, a number N may be used as an argument,
which means to set the ignore count of that breakpoint to N - 1 (so that
the breakpoint won't break until the Nth time it is reached).

If non-stop mode is enabled, continue only the current thread,
otherwise all the threads in the program are continued.  To
continue all stopped threads in non-stop mode, use the /a option.
Specifying /a and an ignore count simultaneously is an error.

-- 
Pedro Alves

[-- Attachment #2: 009-continue_all.diff --]
[-- Type: text/x-diff, Size: 4337 bytes --]

2008-05-09  Pedro Alves  <pedro@codesourcery.com>

	Add "continue /a" option for non-stop mode.

	* infcmd.c (proceed_thread_callback, do_context_switch_to): New.
	(continue_command): Add "/a" option.

---
 gdb/infcmd.c |   80 ++++++++++++++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 69 insertions(+), 11 deletions(-)

Index: src/gdb/infcmd.c
===================================================================
--- src.orig/gdb/infcmd.c	2008-05-08 14:23:26.000000000 +0100
+++ src/gdb/infcmd.c	2008-05-08 18:34:53.000000000 +0100
@@ -607,16 +607,36 @@ start_command (char *args, int from_tty)
   run_command_1 (args, from_tty, 1);
 } 
 
+static int
+proceed_thread_callback (struct thread_info *thread, void *arg)
+{
+  if (is_running (thread->ptid))
+    return 0;
+
+  context_switch_to (thread->ptid);
+  clear_proceed_status ();
+  proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 0);
+  return 0;
+}
+
+static void
+do_context_switch_to (void *arg)
+{
+  ptid_t *ptid = arg;
+  context_switch_to (*ptid);
+}
+
+/* continue [/a] [proceed-count] [&]  */
 void
-continue_command (char *proc_count_exp, int from_tty)
+continue_command (char *args, int from_tty)
 {
   int async_exec = 0;
+  int all_threads = 0;
   ERROR_NO_INFERIOR;
-  ensure_not_running ();
 
   /* Find out whether we must run in the background. */
-  if (proc_count_exp != NULL)
-    async_exec = strip_bg_char (&proc_count_exp);
+  if (args != NULL)
+    async_exec = strip_bg_char (&args);
 
   /* If we must run in the background, but the target can't do it,
      error out. */
@@ -631,9 +651,27 @@ continue_command (char *proc_count_exp, 
       async_disable_stdin ();
     }
 
-  /* If have argument (besides '&'), set proceed count of breakpoint
-     we stopped at.  */
-  if (proc_count_exp != NULL)
+  if (args != NULL)
+    {
+      if (strncmp (args, "/a", sizeof ("/a") - 1) == 0)
+	{
+	  all_threads = 1;
+	  args += sizeof ("/a") - 1;
+	  if (*args == '\0')
+	    args = NULL;
+	}
+    }
+
+  if (!non_stop && all_threads)
+    error (_("/a is meaningless in all-stop mode."));
+
+  if (args != NULL && all_threads)
+    error (_("\
+Can't resume all threads and specify proceed count simultaneously."));
+
+  /* If we have an argument left, set proceed count of breakpoint we
+     stopped at.  */
+  if (args != NULL)
     {
       bpstat bs = stop_bpstat;
       int num, stat;
@@ -643,7 +681,7 @@ continue_command (char *proc_count_exp, 
 	if (stat > 0)
 	  {
 	    set_ignore_count (num,
-			      parse_and_eval_long (proc_count_exp) - 1,
+			      parse_and_eval_long (args) - 1,
 			      from_tty);
 	    /* set_ignore_count prints a message ending with a period.
 	       So print two spaces before "Continuing.".  */
@@ -662,9 +700,24 @@ continue_command (char *proc_count_exp, 
   if (from_tty)
     printf_filtered (_("Continuing.\n"));
 
-  clear_proceed_status ();
+  if (non_stop && all_threads)
+    {
+      /* Don't error out current thread is running, because there may
+	 be other stopped threads.  */
 
-  proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 0);
+      ptid_t current_ptid = inferior_ptid;
+      struct cleanup *old_chain
+	= make_cleanup (do_context_switch_to, &current_ptid);
+      iterate_over_threads (proceed_thread_callback, NULL);
+      /* Restore selected ptid.  */
+      do_cleanups (old_chain);
+    }
+  else
+    {
+      ensure_not_running ();
+      clear_proceed_status ();
+      proceed ((CORE_ADDR) -1, TARGET_SIGNAL_DEFAULT, 0);
+    }
 }
 \f
 /* Step until outside of current statement.  */
@@ -2332,7 +2385,12 @@ This command is a combination of tbreak 
 Continue program being debugged, after signal or breakpoint.\n\
 If proceeding from breakpoint, a number N may be used as an argument,\n\
 which means to set the ignore count of that breakpoint to N - 1 (so that\n\
-the breakpoint won't break until the Nth time it is reached)."));
+the breakpoint won't break until the Nth time it is reached).\n\
+\n\
+If non-stop mode is enabled, continue only the current thread,\n\
+otherwise all the threads in the program are continued.  To \n\
+continue all stopped threads in non-stop mode, use the /a option.\n\
+Specifying /a and an ignore count simultaneously is an error."));
   add_com_alias ("c", "cont", class_run, 1);
   add_com_alias ("fg", "cont", class_run, 1);
 

Re: [RFC] 09/10 Add "continue --all"

[Daniel Jacobowitz]

On Fri, May 09, 2008 at 02:36:09AM +0100, Pedro Alves wrote:
> And after a bit, it hit me that we use /opt most everywhere
> else, so "continue /a" makes more sense?

I don't know; personally I do not like it.  The other slashed options
are all output formatting, even Doug's new /m for disassemble.  This
one is behavior, not option.

Does continue have to handle all threads at once, or is this similar
to "thread apply all continue"?  We could alias all -> thread apply
all.


-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] 09/10 Add "continue --all"

[Pedro Alves]

A Friday 09 May 2008 02:47:20, Daniel Jacobowitz wrote:
> On Fri, May 09, 2008 at 02:36:09AM +0100, Pedro Alves wrote:
> > And after a bit, it hit me that we use /opt most everywhere
> > else, so "continue /a" makes more sense?
>
> I don't know; personally I do not like it.  The other slashed options
> are all output formatting, even Doug's new /m for disassemble.  This
> one is behavior, not option.
>
> Does continue have to handle all threads at once, or is this similar
> to "thread apply all continue"?  

It's basically the same.  I mentioned that upthread.

> We could alias all -> thread apply 
> all.

I love the sound of that!  "all continue".  Perfect.

There's just one difference.  "continue --all" resumes all
threads and prints "Continuing." once, while "all continue" would print
that (or whatever we change it too) once per resuming thread.  That may
actually be better, unless we wanted to compress the output, like

 Continuing all threads
  or
 Continuing thread 2,3,5,7,8,...,20
  vs
 Continuing thread 2
 Continuing thread 3
 Continuing thread 5
 Continuing thread 7
 Continuing thread ...
 Continuing thread 20

But "all continue", "all interrupt", "all ..." seems so perfect that
I'm for all it.

Others?

-- 
Pedro Alves

Re: [RFC] 09/10 Add "continue --all"

[Pedro Alves]

A Friday 09 May 2008 03:07:47, Pedro Alves wrote:
> A Friday 09 May 2008 02:47:20, Daniel Jacobowitz wrote:
> > On Fri, May 09, 2008 at 02:36:09AM +0100, Pedro Alves wrote:
> > > And after a bit, it hit me that we use /opt most everywhere
> > > else, so "continue /a" makes more sense?
> >
> > I don't know; personally I do not like it.  The other slashed options
> > are all output formatting, even Doug's new /m for disassemble.  This
> > one is behavior, not option.
> >
> > Does continue have to handle all threads at once, or is this similar
> > to "thread apply all continue"?
>
> It's basically the same.  I mentioned that upthread.
>
> > We could alias all -> thread apply
> > all.
>
> I love the sound of that!  "all continue".  Perfect.
>
> There's just one difference.  "continue --all" resumes all
> threads and prints "Continuing." once, while "all continue" would print
> that (or whatever we change it too) once per resuming thread.  That may
> actually be better, unless we wanted to compress the output, like
>
>  Continuing all threads
>   or
>  Continuing thread 2,3,5,7,8,...,20
>   vs
>  Continuing thread 2
>  Continuing thread 3
>  Continuing thread 5
>  Continuing thread 7
>  Continuing thread ...
>  Continuing thread 20
>
> But "all continue", "all interrupt", "all ..." seems so perfect that
> I'm for all it.
>

Oh, I was so happy with the syntax that I forgot about one big
difference...

"continue"
is giving the user an error if the current thread is already running,
(and -exec-continue too, by consequence).

"continue --all" was resuming all stopped threads and leaving the running
threads alone, hence there was no error if any thread was already running
(last patch was better at that than the previous one).

Given that "continue" errors on a running thread, "all continue" will
then give an error as soon as it tries to resume one of the running
threads, because it's calling continue in sucession.  I don't
think is a good behaviour for the user.

What to do?

- Silently ignore if user tries to continue a running thread in "continue"?

  The threads that are stepping, will remain stepping.  Perhaps not silently,
  but with a warning?

  What about the MI side?  A frontend should know better
  than a user about the running state of a thread, so, -exec-continue 
  shouldn't really be allowed on a running thread, right?
  We could make MI not call "continue --all&" but implement the
  required functionality in a convenience function for MI, say, or a 
  "continue -e" - error-if-running option...

- Override the step of a running thread and turn it into a continue?

  That's tricky, and it gets to the phase of
  debugger-trying-to-be-smart-for-the-user.  I don't want to go
  there.  An error-if-running meant the user got to decide what
  to do (interrupt; continue, for example).  And an MI client should
  not be requesting such things -- it can always interrupt;continue 
  programatically, if such functionality is desired on a frontend.
  Normally, if a thread is stepping, the "resume" action is just
  shaded/disabled, and the user has only access to "suspend"
  the thread.  KISS.

- Keep throwing an error with "continue" on running thread, and
  really add "continue -a,--all,?" ?

  "-exec-continue --all" (or '-exec-continue --thread="all"')
  is mappeable cleanly to "continue --all" but it's not to "all continue"
  if we want to add some output smartness in a single command invocation
  (vs multiple invocations of continue).  We can always implement the  
  --all funcionality on the MI side only of course.

> Others?

-- 
Pedro Alves

Re: [RFC] 09/10 Add "continue --all"

[Daniel Jacobowitz]

On Fri, May 09, 2008 at 01:08:28PM +0100, Pedro Alves wrote:
> - Keep throwing an error with "continue" on running thread, and
>   really add "continue -a,--all,?" ?

If you like the all prefix, then we can keep it even if it isn't
strictly an alias to thread apply all.  One way would be to register
subcommands of "thread apply all" just as all is registered as a
subcommand of thread; the help is not very clear about this but you
can specify "thread apply 1", too.  Another way would be to allow
commands to internally register a special function to be called under
apply-to-all.

If you don't like the all prefix then we can go back to continue
--all, or even just continue all.  Continue takes a numeric argument
and all will not conflict.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] 09/10 Add "continue --all"

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> If you don't like the all prefix then we can go back to continue
> --all, or even just continue all.  Continue takes a numeric argument
> and all will not conflict.

That doesn't sound very future proof. Somebody might like to refer to 
named threads some day (our thread implementation has names, although 
the debugger doesn't accept them as input just yet).

How about just "continueall" and "ca"?

Andrew

Re: [RFC] 09/10 Add "continue --all"

[Joel Brobecker]

> If you don't like the all prefix then we can go back to continue
> --all, or even just continue all.  Continue takes a numeric argument
> and all will not conflict.

FWIW, I like "continue all", but I think I prefer the "all" prefix.
I would probably have "all continue" be its own command rather
than having it an alias of "thread apply all continue" for the
reasons that Pedro mentioned, and it shouldn't be much more work than
the solution based on command aliasing.

Using the "all" command prefix would be very elegant when we add
more commands.  This assumes that there are other commands that
we'd like to provide under that same prefix.

-- 
Joel

Re: [RFC] 09/10 Add "continue --all"

[Pedro Alves]

A Sunday 11 May 2008 17:00:01, Joel Brobecker wrote:
> > If you don't like the all prefix then we can go back to continue
> > --all, or even just continue all.  Continue takes a numeric argument
> > and all will not conflict.
>

I hadn't proposed continue all, because we evaluate the integer
as an expression, so that prevents the highly dubious
valued form of using the contents of a variable named "all" in
the inferior with "continue all".  "thread apply n" has the same
issue, so I realized that it's a moot concern.  :-)

> FWIW, I like "continue all", but I think I prefer the "all" prefix.
> I would probably have "all continue" be its own command rather
> than having it an alias of "thread apply all continue" for the
> reasons that Pedro mentioned, and it shouldn't be much more work than
> the solution based on command aliasing.
>
> Using the "all" command prefix would be very elegant when we add
> more commands.  This assumes that there are other commands that
> we'd like to provide under that same prefix.

I'm still not sure.  Will we allow later to do things like:

'continue -t 4' -> continue thread 1, even though I have selected
thread 1.

Which would be the same as -exec-continue --thread="4".

?

'continue -a' feels like an extension to that.

OTOH, Should we have "thread apply all stopped do_x",
and "thread apply all all running" instead?
Could be aliased to allr, alls, for example.

-- 
Pedro Alves

Re: [RFC] 09/10 Add "continue --all"

[Michael Snyder]

On Mon, 2008-05-19 at 16:20 +0100, Pedro Alves wrote:
> A Sunday 11 May 2008 17:00:01, Joel Brobecker wrote:
> > > If you don't like the all prefix then we can go back to continue
> > > --all, or even just continue all.  Continue takes a numeric argument
> > > and all will not conflict.
> >
> 
> I hadn't proposed continue all, because we evaluate the integer
> as an expression, so that prevents the highly dubious
> valued form of using the contents of a variable named "all" in
> the inferior with "continue all".  

This is a very valid concern.  Can't have ambiguity.

What about "continue /all"?  More in keeping with the
argument syntax of existing gdb commands (print, examine...)

Re: [RFC] 09/10 Add "continue --all"

[Daniel Jacobowitz]

On Mon, May 19, 2008 at 11:19:42AM -0700, Michael Snyder wrote:
> What about "continue /all"?  More in keeping with the
> argument syntax of existing gdb commands (print, examine...)

So far there are only single letter specifiers, and they're all output
formats (print/x, disassemble/m).  Adding multi-letter ones
would be pretty confusing, IMO.

If we want functionality arguments, especially multi-letter ones, I
have a small preference for --all.

Well, that's my two cents.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] 09/10 Add "continue --all"

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> On Mon, May 19, 2008 at 11:19:42AM -0700, Michael Snyder wrote:
>> What about "continue /all"?  More in keeping with the
>> argument syntax of existing gdb commands (print, examine...)
>
> So far there are only single letter specifiers, and they're all output
> formats (print/x, disassemble/m).  Adding multi-letter ones
> would be pretty confusing, IMO.
>
> If we want functionality arguments, especially multi-letter ones, I
> have a small preference for --all.

IMHO the best fit in the current cli syntax would be a subcommand.  Any
ambiguity can be resolved the same way as `set variable'.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."