Unbreak 'catch syscall' + multi-threading
Pedro Alves <pedro <at> codesourcery.com>
2009-10-01 00:48:16 GMT
As we were discussing yesterday, 'catch syscall' is unfortunately
broken with multi-threading in the mix, plus it has a few other
problems (present on 7.0 too, of course). This patch fixes all the
issues I found.
- "detach" when stopped at a syscall event dies horribly. This was
because we'd try to pass signal 0x85 to the inferior (SIGTRAP | 0x80, with
0x80 being the magic sysgood/syscall bit). We should never pass a
ptrace SIGTRAP to the inferior. get_pending_status was fixed to handle
that., and I ended up simpl
- In a multi-threaded app+all-stop: when gdb stops all threads to report
an event, and some other thread hits a syscall trap, that event is left
pending, but then a few issues trigger: the entry/return state of the
syscall ends up inverted; if the user removes the syscall catchpoint
before resuming, the pending event ends up reported as a spurious
SIGTRAP or ??? signal (SIGTRAP | 0x80). I've spend a good bit
figuring out how/when syscall traps are reported, and what
happens (at least on my kernel 2.6.24 x86_64) when we PTRACE_CONT
to collect a pending SIGSTOP. I've added hopefully compreensive
(and correct!) explanations to the patch. I wouldn't mind a double
check.
- Related to the previous point, even when not interested in a given
syscall event, we'd still always stop all threads, report the event
to the core, only to have the core immediately resume all threads
again. I've made it so that if we're ignoring the event, we
resume the lwp hat reported the syscall immediately on the target
side, bypassing the slow all-threads stop/resume.
(Continue reading)