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

[Josh Stone <jistone at redhat dot com>]

On 03/30/2016 05:23 AM, Yao Qi wrote:
> 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.

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 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
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.)


BTW, even x86 is a little suspect if you cross compat modes.  The number
is preserved in orig_rax, but if you exec'ed from a 64-bit process to
32-bit, that number would still be the 64-bit NR_execve.  It happens to
still apparently work in that case because gdb isn't reloading its
syscall mapping.  But continue and it next gets:

Catchpoint 2 (call to syscall recvfrom), 0xf7ff29b9 in brk () from
/lib/ld-linux.so.2

i.e. 32-bit syscall brk is incorrectly called recvfrom.

>> 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.
>