[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