This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]