This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] Fix PR 2250 - multithreaded single-step problems in all-stop mode
- From: Pedro Alves <pedro at codesourcery dot com>
- To: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Cc: gdb-patches at sourceware dot org, drow at false dot org
- Date: Mon, 17 Nov 2008 19:48:33 +0000
- Subject: Re: [rfc] Fix PR 2250 - multithreaded single-step problems in all-stop mode
- References: <200811171856.mAHIuMHs011334@d12av02.megacenter.de.ibm.com>
On Monday 17 November 2008 18:56:22, Ulrich Weigand wrote:
> B.t.w. what about init_execution_control_state? This seems to
> be nowhere called ...
Hmm, good catch. It seems that got left behind when I pulled
all that was context-switched out of struct execution_control_state
(which is now a bit mis-named).
There used to be a call to init_execution_control_state in
wait_for_inferior around where now there's a memset, so we're
not missing anything (clearing ecs->random_signal).
I don't think there's any reason to keep random_signal
untouched across handle_inferior_event invocations in the while (1)
loop in wait_for_inferior ? --- handle_inferior_event seems
to set or clear it itself before relying on its value, but I wouldn't
be that surprised there's a weird twisted code path where that isn't
happening, and we could be reading a random_signal from a previous stop.
Maybe moving the memset to inside the while (1) loop in
wait_for_inferior would make things a bit clearer (if my reasoning
about random_signal not being needed across events is correct).
--
Pedro Alves