Re: [rfc][rft (procfs, nto-procfs)] Fix signal bypass heuristic with software single-step

Ulrich Weigand
2011-03-24T15:50:41Z

Pedro Alves wrote:

> As discussed before, I like the approach, but I have a couple of remarks
> to the implementation:

Thanks for the review!

> - There are more calls to target_resume in infrun.c. Don't we need
> to consider signals around those?

Hmm, that's true.

> - In non-stop, if you have this sequence:
>
> - step thread 1
> - continue thread 2 (imediately afterwards)
> - thread 1 gets signal FOO (which is normally pass-able).
>
> when handling the latter event, since the "signal_pass" set is
> global, and has been filled by the previous continue, the target
> will think it doesn't need to report the signal back to core gdb.
>
> You've said before about this when I raised the issue before:
>
> "If the implementation is conservative in the right direction,
> the worst thing that could happen is that a signal is reported that
> might have gotten short-circuited .."
>
> Might be we just need to check if _any_ thread is stepping, when
> deciding whether to tell the target to report back all signals?

Right, that seems correct to me.

Tom Tromey wrote:

> I would like it if there were more documentation about what this method
> means and how it is used. Actually, I suppose I would prefer it on the
> field in struct target_ops, to be read by people porting gdb.

Good point, agreed.

I'll work on another update of the patch ...

Bye,