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

["Pierre Muller" <muller@ics.u-strasbg.fr>]

 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