[PATCH v4] Implement 'catch syscall' for gdbserver
Josh Stone
jistone@redhat.com
Fri Apr 1 16:38:00 GMT 2016
On 04/01/2016 06:05 AM, Yao Qi wrote:
> Josh Stone <jistone@redhat.com> writes:
>
>> Well, sure, but I have no idea where that somewhere else could be.
>>
>> Note these architectures do work for other syscall returns. It's just
>> that execve is a bit special by switching the whole process out.
>
> I talked with a kernel people, looks GDB can't fetch the syscall number
> on execve exit.
>
>>
>> I suppose we could try to save the number on syscall entry, and just
>> report that again when it returns. But it's not 100% sure that we'll
>
> Yes, that is what I am thinking too.
I guess then it's a question whether we try to save this as much as
possible, or only for cases that look like execve (on entry).
>> see every entry first. For instance, one could 'catch execve' first,
>> which will continue until PTRACE_EVENT_EXEC mid-syscall, then turn on
>> 'catch syscall' and see what returns.
>> (This is similar to what test_catch_syscall_mid_vfork checks.)
>
> Yeah, we can't guarantee syscall enter comes into first. I doubt
> 'lp->syscall_state' is confused in this case too, no?
This is one of the things I fixed. We know that events like
PTRACE_EVENT_EXEC are mid-syscall, even if we didn't see the entry, so a
syscall event that follows must be a return. And other ptrace stops are
never mid-syscall, so a syscall that follows those must be an entry.
This is set in linux_handle_extended_wait and wait_lwp.
More information about the Gdb-patches
mailing list