This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH v4] Implement 'catch syscall' for gdbserver
- From: Josh Stone <jistone at redhat dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: Pedro Alves <palves at redhat dot com>, gdb-patches at sourceware dot org, philippe dot waroquiers at skynet dot be, sergiodj at redhat dot com, eliz at gnu dot org, xdje42 at gmail dot com, scox at redhat dot com
- Date: Fri, 1 Apr 2016 09:38:03 -0700
- Subject: Re: [PATCH v4] Implement 'catch syscall' for gdbserver
- Authentication-results: sourceware.org; auth=none
- References: <1449196006-13759-2-git-send-email-jistone at redhat dot com> <1452308954-13679-1-git-send-email-jistone at redhat dot com> <5694EC0E dot 2080904 at redhat dot com> <56954F8C dot 6010100 at redhat dot com> <56955283 dot 1060502 at redhat dot com> <56955B84 dot 7050905 at redhat dot com> <86mvphs6kv dot fsf at gmail dot com> <56FAC588 dot 6060200 at redhat dot com> <56FB1486 dot 60208 at redhat dot com> <86io04rw7k dot fsf at gmail dot com> <56FC78E3 dot 6020300 at redhat dot com> <86bn5tqy29 dot fsf at gmail dot com>
On 04/01/2016 06:05 AM, Yao Qi wrote:
> Josh Stone <email@example.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.