[PATCH v4] Implement 'catch syscall' for gdbserver
Yao Qi
qiyaoltc@gmail.com
Wed Mar 30 12:23:00 GMT 2016
Josh Stone <jistone@redhat.com> writes:
Hi Josh,
Thanks for the looking into this...
> 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.
I think it reveals a bug on getting syscall number. If the register
having syscall number isn't preserved across the syscall, GDB should
read syscall number somewhere else.
>
> 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.
--
Yao (齐尧)
More information about the Gdb-patches
mailing list