This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] linux-nat: Never PTRACE_CONT a stepping thread
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Date: Sat, 16 Oct 2010 18:09:52 +0100
- Subject: Re: [rfc] linux-nat: Never PTRACE_CONT a stepping thread
- References: <20100921234325.GA31267@host1.dyn.jankratochvil.net>
On Wednesday 22 September 2010 00:43:25, Jan Kratochvil wrote:
> Hi,
>
> as referenced in:
> [patch 3/4]#3 linux-nat: Do not respawn signals
> http://sourceware.org/ml/gdb-patches/2010-09/msg00360.html
>
> If multiple signals happen besides SIGTRAP GDB still may switch from thread A
> away (as not considering it stepping) to thread B for SIGUSR1 and accidentally
> PTRACE_CONT thread A while resignalling SIGUSR1.
Yeah. I think you should put this in.
> It probably could have its own testcase.
> I will code one depending on the resolution of the #3 series above.
This patch alone on top of current mainline fixes the sigstep-threads.exp
test from <http://sourceware.org/ml/gdb-patches/2010-09/msg00360.html>.
Maybe check that test in along with this patch?
The corresponding remote.c patch (pasted below) that translates this
into a vCont with three actions (e.g., "vCont;C1e:795a;s:7959;c") also
fixes that test for gdbserver linux.
> --- a/gdb/infrun.c
> +++ b/gdb/infrun.c
> -static int
> +int
> currently_stepping (struct thread_info *tp)
> {
It'd be much cleaner to make the target_resume interface similar
to gdbserver's target_ops->resume interface (pass in a list of
resume actions, similar to vCont), but that shouldn't be a
prerequisite. Maybe someday...
--
Pedro Alves
---
gdb/remote.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
Index: src/gdb/remote.c
===================================================================
--- src.orig/gdb/remote.c 2010-10-16 17:20:41.000000000 +0100
+++ src/gdb/remote.c 2010-10-16 18:02:02.000000000 +0100
@@ -4416,6 +4416,12 @@ append_resumption (char *p, char *endp,
return p;
}
+static int
+currently_stepping_callback (struct thread_info *tp, void *data)
+{
+ return currently_stepping (tp);
+}
+
/* Resume the remote inferior by using a "vCont" packet. The thread
to be resumed is PTID; STEP and SIGGNAL indicate whether the
resumed thread should be single-stepped and/or signalled. If PTID
@@ -4458,6 +4464,8 @@ remote_vcont_resume (ptid_t ptid, int st
}
else if (ptid_equal (ptid, minus_one_ptid) || ptid_is_pid (ptid))
{
+ struct thread_info *tp;
+
/* Resume all threads (of all processes, or of a single
process), with preference for INFERIOR_PTID. This assumes
inferior_ptid belongs to the set of all threads we are about
@@ -4468,6 +4476,12 @@ remote_vcont_resume (ptid_t ptid, int st
p = append_resumption (p, endp, inferior_ptid, step, siggnal);
}
+ tp = iterate_over_threads (currently_stepping_callback, NULL);
+ if (tp && !ptid_equal (tp->ptid, inferior_ptid))
+ {
+ p = append_resumption (p, endp, tp->ptid, 1, TARGET_SIGNAL_0);
+ }
+
/* And continue others without a signal. */
p = append_resumption (p, endp, ptid, /*step=*/ 0, TARGET_SIGNAL_0);
}