This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc] linux-nat: Never PTRACE_CONT a stepping thread

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
> 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 <>.
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);

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]