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
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
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 trap,
- 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?
