Re: [rfc][2/2] Signal delivery + software single-step is broken

[Pedro Alves <pedro at codesourcery dot 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