On 11/02, Roland McGrath wrote:
>
> > - unlike send_sigtrap()->force_sig_info() we don't unblock
> > SIGTRAP or reset the handler
>
> This is nicer for debugger things actually, but we don't have such niceness
> for real traps and won't soon. IMHO it is best to start with doing exactly
> what the old x86 code does, which is force_sig_info--which is also making
> all machines uniformly do "what a real single-step trap does" and is thus
> consistent in this PTRACE_SINGLESTEP case matching all others, which we
> have been saying is a sensible principle.
>
> > these changes looks good (but see the next patch). However, any
> > user-visible change is dangerous.
>
> Let's not roll it in. As well as it just being bad form to roll that into
> implementation detail changes, it makes things less consistent rather than
> more (on x86, anyway, and arguably across the board).
OK.
So, we should revert this change and send the trap from ptrace_resume(),
- instead of send_sigtrap() we should use user_single_step_siginfo()
+ force_sig_info()
- PTRACE_EVENT_SYSCALL_EXIT shouldn't send the trap, this was
x86 specific behaviour, and this is fixed in upstream by
[PATCH v2 5/5] ptrace: x86: change syscall_trace_leave() to rely on
tracehook when stepping
we recently sent.
(btw, I wrongly thought x86 is right and other machines should
be fixed).
Correct?
If yes:
- force_sig_info() needs tasklist_lock.
we can change force_sig_info() to use lock_task_sighand(),
but perhaps we should not worry about this now
- what should we do with PTRACE_EVENT_SIGTRAP ?
> So, get rid of PTRACE_EVENT_SIGTRAP. Instead for the case of
> UTRACE_SIGNAL_HANDLER when stepping, initialize *info to look
> like a vanilla SIGTRAP and then fall into the default case for
> real signals.
should UTRACE_SIGNAL_HANDLER use force_sig_info() too or
it can just deliver this *info as you initially suggested ?
Or we can forget about this change for now?
I agree in advance with everything you prefer, you definetely
know better.
Anything else I missed?
Oleg.
