On 11/13, Roland McGrath wrote:
>
> > Nothing wrong (I think), but this is more complex and implies more
> > unnecessary work.
>
> You mean the code path taken is longer. But the code's logic remains simple.
The logic a bit complicated too, because ctx->signr is overloaded.
Otohm, I don't like to
> Nothing wrong (I think), but this is more complex and implies more
> unnecessary work.
You mean the code path taken is longer. But the code's logic remains simple.
> If ptrace_report_signal() sends the trap, we actually send the signal
> twice. Firstly ptrace_resume() does utrace_control(UTRAC
On 11/12, Roland McGrath wrote:
>
> > So, we should revert this change and send the trap from ptrace_resume(),
>
> What's wrong with ptrace_report_signal doing it?
Nothing wrong (I think), but this is more complex and implies more
unnecessary work.
If the trap is sent by ptrace_resume() everythin
> So, we should revert this change and send the trap from ptrace_resume(),
What's wrong with ptrace_report_signal doing it?
> - instead of send_sigtrap() we should use user_single_step_siginfo()
> + force_sig_info()
Right.
> - PTRACE_EVENT_SYSCALL_EXIT shouldn't send the tra
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
>
> - it sets task->thread.trap_no/error_code under CONFIG_X86,
> what should it do in the #else case?
This can't be this way. It has to be a proper arch hook of some kind.
> - it sets info->si_addr = KSTK_EIP() which doesn't check
> user_mode_vm(). Hopefully this is OK
Move send_sigtrap() logic from ptrace_resume() to ptrace_report_signal().
ptrace_resume() sets ctx->signr = SIGTRAP and returns UTRACE_INTERRUPT.
ptrace_report_signal() notices SIGTRAP, fills *info and reports the signal.
fill_sigtrap_info() mimics x86-specific send_sigtrap(), therefore:
