From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: "Ulrich Weigand" <uweigand@de.ibm.com>
Subject: Re: [rfc][2/2] Signal delivery + software single-step is broken
Date: Wed, 19 Jan 2011 18:48:00 -0000 [thread overview]
Message-ID: <201101191124.25977.pedro@codesourcery.com> (raw)
In-Reply-To: <201101191642.p0JGgntq023362@d06av02.portsmouth.uk.ibm.com>
On Wednesday 19 January 2011 09:42:49, Ulrich Weigand wrote:
> even with the previous patch, some sigstep.exp tests are still failing.
> This is due to a peculiarity of the linux-nat target, which sometimes
> decides to *not* report a signal event to GDB's main event loop, but
> simply re-dispatch the inferior directly.
>
> This is broken if GDB actually needs to handle signal delivery specially,
> which is in particular the case if we're currently single-stepping.
> Therefore, linux-nat refrains from such by-passing of the main event
> loop if single-stepping is in progress. However, it does so by simply
> checking the "step" flag that was passed to its resume implementation.
> But this flag will always be zero on targets that do software single-
> stepping -- but those also must not bypass signal delivery ...
>
> The patch below changes linux_nat_wait_1 to actually look at the stepping
> status of the thread directly, instead of relying on the "step" flag.
> This means the "currently_stepping" routine has to be exported from
> infrun.c so it can be called here.
>
> Thoughts?
I'm not objecting, but I'm curious on whether you've thought about how
the same problem would be solved in gdbserver/linux-low.c, which
can't call currently_stepping, since it's running in a different process?
One way to do it would be to do:
QPassSignals:
vCont;c
QPassSignals:foo;bar
but that is a lot of extra roundtrips, and not really (inferior) threadsafe in
non-stop mode.
It sounds like we'd need to tweak the target resume interface to be
able to say "continue, but I'm interested in signals and everything else",
or, "I'm telling you to continue, but you're really single-stepping",
like a new vCont;cs or some such?
If we end up needing something like this, then we'd use the same
interface for linux nat.
--
Pedro Alves
next prev parent reply other threads:[~2011-01-19 18:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-19 17:12 Ulrich Weigand
2011-01-19 18:48 ` Pedro Alves [this message]
2011-01-19 18:57 ` Ulrich Weigand
2011-01-19 20:40 ` Pedro Alves
2011-01-20 23:28 ` Ulrich Weigand
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=201101191124.25977.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=uweigand@de.ibm.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).