This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [RFC] 09/10 Add "continue --all"
- From: "Pierre Muller" <muller at ics dot u-strasbg dot fr>
- To: "'Pedro Alves'" <pedro at codesourcery dot com>, <gdb-patches at sourceware dot org>
- Date: Wed, 7 May 2008 10:21:53 +0200
- Subject: RE: [RFC] 09/10 Add "continue --all"
- References: <200805061649.50105.pedro@codesourcery.com>
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