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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

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,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com