[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