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

[Pedro Alves <pedro at codesourcery dot com>]

On Wednesday 27 April 2011 20:11:53, Ulrich Weigand wrote:
> :-)
> The problem is that if a step-resume breakpoint is installed,
> handle_inferior_event will never expect hardware single-step
> traps (unless a software watchpoint is also in effect), because
> it assumes nobody ever uses a step-resume breakpoint and then
> hardware single-steps as well (because currently_stepping
> returns 0 in that case).
> 
> The simple way to fix the inconsistency would be to just add a
>   step = 0;
> line to the above if.  Of course this changes the behaviour for
> hardware single-step platforms: they now would not step into
> the signal handler in this case (just like software single-step
> platforms don't).
> 
> On the one hand, this adds consistency: both types of platforms
> behave the same.  

IIUC, with that change alone, the behavior on hw-step archs
would change depending on there being a breakpoint at PC or
not.  Without a breakpoint, you'd step into the handler, with
a breakpoint, you'd not.

> (On software single-step platforms, it seems
> we simply cannot step into the handler, because we can't find
> it.)

IMO, this could/should be fixed with kernel help.

> 
> On the other hand, in some sense this reduces functionality.
> So one could try to treat the two platforms separately, and
> have hardware single-step platforms step into the handler,
> even while software single-step platforms don't.
> 
> [ This would probably mean to move support back into resume,
> because we'd want to do that only if we actually use software
> single-step for this particular step.  ]
> 
> Thoughts?  Which behaviour would you prefer?

I'd prefer to keep the possibility to step into a handler.
I find this very useful when you don't actually know what
handler is installed.  Much easier than grepping for "signal" and
trying to guess what is installed (which may even have been done
by some external dependency / library).

-- 
Pedro Alves