This is the mail archive of the
gdb-patches@sourceware.org
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: Tue, 29 Mar 2016 16:49:26 -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>
On 03/29/2016 11:12 AM, Josh Stone wrote:
> On 03/29/2016 07:26 AM, Yao Qi wrote:
>> Hi Josh,
>> This commit causes some fails on s39x, and ppc, as shown in buildbot. I
>> saw them in aarch64 test as well. Could you take a look?
>>
>> https://sourceware.org/ml/gdb-testers/2016-q1/msg01544.html
>> https://sourceware.org/ml/gdb-testers/2016-q1/msg01601.html
>
> Hmm. That new test is meant to make sure that the syscall entry/return
> state is not lost across an execve. In the failure I knew, the execve
> return was interpreted as an additional syscall entry. But in the cases
> you've shown, it didn't catch syscall return from execve at all!
>
> I will investigate more...
So, it seems those architectures don't preserve their original syscall
numbers across an execve.
$ gdb -ex 'catch syscall execve' -ex 'run' -ex 'catch syscall' \
-ex 'continue' --args sh -c /bin/true
PPC64 and Aarch64 both read their syscall numbers from registers, and
here they both get 0 ("restart_syscall" and "io_setup" respectively).
S390X tries to decode it from the SVC instruction at PC-2, which will
definitely fail after an execve -- gdb reports syscall -1.
So when the catchpoint is only for execve, they continue past this one
since the number doesn't look like execve.
The good news is that all three do call it a syscall *return*, which was
the main point of this particular test. If there's no objection, I can
try to update the test to work more like my command above, matching any
syscall at all on the return side of execve.