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

["Ulrich Weigand" <uweigand@de.ibm.com>]

Pedro Alves wrote:
> On Wednesday 19 January 2011 11:48:20, Ulrich Weigand wrote:
> > Presumably because of this, gdbserver today does not appear to be
> > implementing this particular optimization at all, but always reports
> > all signals back to GDB to decide what to do with them.
> 
> It does implement it.  It's done in gdbserver/linux-low.c:linux_wait_1.
> Look for:
> 
> 	  (pass_signals[target_signal_from_host (WSTOPSIG (w))]

D'oh, I somehow completely missed that.  Sorry.

> In linux-nat.c's case, stop_soon used to be set to STOP_QUIETLY
> while doing the startup_inferior dance, but it no longer does ever
> since you've rewriten startup_inferior to not use wait_for_inferior,
> but use target_resume/target_wait directly, I think.  I guess it
> may be a bug that stop_soon is no longer set in that case?

Actually, IIRC one of the reasons for the startup_inferior was to
*get away* from using the magic stop_soon flag to influence the
behaviour in somewhat under-defined ways, but instead just directly
handle whatever events we expect here.  I probably wasn't aware that
the *target* itself directly uses the flag too ...

In any case, if we move to a solution where we toggle the signal
pass flags as needed, we should simply set all signals to non-pass
during startup too.

> The flag is also set to STOP_QUIETLY in svr4_solib_create_inferior_hook,
> but that's in code that only gets built for SCO.  In this case,
> if we cared for SCO, I'd say we'd wrap the loop in
> svr4_solib_create_inferior_hook with the same
> QPassSignals dance (the target method in question
> is target_notice_signals, btw).

Right.

I'll see if I can come up with a patch ...

Bye,
Ulrich

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