Re: [PATCH v4] Implement 'catch syscall' for gdbserver

[Josh Stone <jistone at redhat dot com>]

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.