Martin, sorry for delay,
On 01/07, Martin Schwidefsky wrote:
On Wed, 6 Jan 2010 13:13:29 -0800 (PST)
Roland McGrath rol...@redhat.com wrote:
However, with or without CONFIG_UTRACE,
6580807da14c423f0d0a708108e6df6ebc8bc83d
is needed on s390 too, otherwise the child gets unnecessary
On 01/07, Martin Schwidefsky wrote:
On Wed, 6 Jan 2010 13:08:12 -0800 (PST)
Roland McGrath rol...@redhat.com wrote:
That's what tracehook_signal_handler is for. You're both doing it yourself
in the arch code (by setting TIF_SINGLE_STEP), and then telling the generic
code to do it (by
Right. That means we should leave the status quo of not clearing
TIF_SINGLE_STEP in user_disable_single_step.
Ok, although it seems a bit strange not to do it. Perhaps I should add a
comment about it.
It doesn't seem strange to me, but then I've just been through all this.
user_*_step is
Hmm, command for tracehook_signal_handler say this for stepping:
@stepping: nonzero if debugger single-step or block-step in
use
Are you saying you would like me to clarify that wording somehow? It's
meant to be implicit that the arch code is not doing any special fakery
about
Clear the TIF_SINGLE_STEP bit in copy_thread. If the new process is
not auto-attached by the tracer it is wrong to delivere SIGTRAP to
the new process.
The change is right, but this log entry is confusing. auto-attached has
nothing to do with it, nor does anything about tracing the new
I am confused as well. Yes, I thought about regs-psw.mask change too,
but I don't understand why it helps..
[...]
But. Acoording to the testing I did (unless I did something wrong
again) this patch doesn't make any difference in this particular
case. 6580807da14c423f0d0a708108e6df6ebc8bc83d
