From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>
Subject: Re: [rfc] linux-nat: Never PTRACE_CONT a stepping thread
Date: Sat, 16 Oct 2010 17:10:00 -0000 [thread overview]
Message-ID: <201010161809.53308.pedro@codesourcery.com> (raw)
In-Reply-To: <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);
}
next prev parent reply other threads:[~2010-10-16 17:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-22 9:43 Jan Kratochvil
2010-10-16 17:10 ` Pedro Alves [this message]
2010-10-17 18:28 ` Jan Kratochvil
2010-10-17 19:04 ` Pedro Alves
2010-10-18 8:51 ` Jan Kratochvil
2010-10-19 19:24 ` Pedro Alves
2010-11-02 1:56 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201010161809.53308.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).