Now I realized I don't really understand what ->last_siginfo is.
Of course, get_signal_to_deliver() case is clear. But I don't
understand why ptrace_notify() setups ->last_siginfo? (I am talking
about the currrent !utrace code).
What for? OK, I guess .si_code = exit_code is useful, and we should
be compatible anyway.
Now, how we can implement this? The obvious solution is to add
"struct siginfo info" into ptrace_context, but this is a bit ugly.
We need the pointer in ->context, yes. But can't we avoid adding
128 bytes to ptrace_context?
I mean, can't we do the following (please remember, I am ignoring
signals to simplify the discussion):
ptrace_setsiginfo(...) does nothing.
ptrace_getsiginfo(...)
{
if (!context->stopped_code)
// do_signal_stop() case
return -EINVAL;
info->si_code = context->stopped_code;
info->si_signo = SIGTRAP;
}
?
Sure. This can break the test-case or stupid application which writes
something to ->last_siginfo via ptrace_getsiginfo(), then reads the data
back via ptrace_setsiginfo() and expects the "correct" results.
Can we live with this?
I'd really like to avoid 128 unneeded bytes in ->context. Perhaps you
have other ideas?
Oleg.
