Re: [RFC 1/3] [gdb] Call gdbarch_get_syscall_number less often

[Tom de Vries <tdevries@suse.de>]

On 11/21/23 01:29, John Baldwin wrote:
> On 11/20/23 8:12 AM, Simon Marchi wrote:
>> On 11/20/23 10:37, Tom de Vries wrote:
>>> When running test-case gdb.base/catch-syscall.exp on 
>>> powerpc64le-linux, we run
>>> into an xfail:
>>> ...
>>> (gdb) catch syscall execve^M
>>> Catchpoint 18 (syscall 'execve' [11])^M
>>> (gdb) PASS: gdb.base/catch-syscall.exp: execve: \
>>>    catch syscall with arguments (execve)
>>>    ...
>>> continue^M
>>> Continuing.^M
>>> ^M
>>> Catchpoint 18 (call to syscall execve), 0x00007ffff7d7f18c in execve 
>>> () from \
>>>    /lib64/libc.so.6^M
>>> (gdb) PASS: gdb.base/catch-syscall.exp: execve: program has called 
>>> execve
>>> continue^M
>>> Continuing.^M
>>> process 60484 is executing new program: catch-syscall^M
>>> ^M
>>> Breakpoint 17, main (argc=1, argv=0x7fffffffe618) at 
>>> catch-syscall.c:54^M
>>> 54              char buf1[2] = "a";^M
>>> (gdb) XFAIL: gdb.base/catch-syscall.exp: execve: syscall execve has 
>>> returned
>>> ...
>>>
>>> The problem is that the catchpoint "(return from syscall execve)" 
>>> doesn't
>>> trigger.
>>>
>>> This is caused by ppc_linux_get_syscall_number returning 0 at execve
>>> syscall-exit-stop, while it should return 11.
>>>
>>> This is a problem that was fixed in linux kernel version v5.19, by 
>>> commit
>>> ec6d0dde71d7 ("powerpc: Enable execve syscall exit tracepoint"), but the
>>> machine I'm running the tests on has v4.18.0.
>>>
>>> An approach was discussed in the PR where 
>>> ppc_linux_get_syscall_number would
>>> try to detect an execve syscall-exit-stop based on the register 
>>> state, but
>>> that was considered too fragile.
>>>
>>> Fix this by caching the syscall number at syscall-enter-stop, and 
>>> reusing it
>>> at syscall-exit-stop.
>>>
>>> This is sufficient to stop triggering the xfail, so remove it.
>>>
>>> It's good to point out that this doesn't always eliminate the need to 
>>> get the
>>> syscall number at a syscall-exit-stop.
>>>
>>> The test-case has an example called mid-vfork, where we do:
>>> - catch vfork
>>> - continue
>>> - catch syscall
>>> - continue.
>>>
>>> The following things happen:
>>> - the "catch vfork" specifies that we capture the PTRACE_EVENT_VFORK 
>>> event.
>>> - the first continue runs into the event
>>> - the "catch syscall" specifies that we capture syscall-enter-stop and
>>>    syscall-exit-stop events.
>>> - the second continue runs into the syscall-exit-stop.  At that point 
>>> there's
>>>    no syscall number value cached, because no corresponding 
>>> syscall-enter-stop
>>>    was observed.
>>
>> Thanks for this example, it answers a question I had in the PR.
>>
>>> We can address this issue somewhat by translating events into 
>>> syscalls.  A
>>> followup patch in this series use this approach (though not for vfork).
>>>
>>> This is an RFC at this point.
>>>
>>> I think there's an open issue with this patch: the cache needs to be
>>> invalidated when we stop tracking syscalls.  I wonder if a 
>>> generation_counter
>>> scheme would be a good approach here.
>>>
>>> Perhaps we can do a per-thread approach where when continuing a 
>>> thread we
>>> reset the cached value unless PTRACE_SYSCALL is used to continue the 
>>> thread.
>>
>> I think that last idea makes sense.  I am not sure I undertsand the
>> generation_counter idea.
> 
> Regarding the generation counter, my understanding is that the native Linux
> target never disables syscall tracing once it is enabled, or at least 
> that is
> what the comment in linux-nat.c implies to me:
> 
> int
> linux_nat_target::set_syscall_catchpoint (int pid, bool needed, int 
> any_count,
>                        gdb::array_view<const int> syscall_counts)
> {
>    /* On GNU/Linux, we ignore the arguments.  It means that we only
>       enable the syscall catchpoints, but do not disable them.
> 
>       Also, we do not use the `syscall_counts' information because we do 
> not
>       filter system calls here.  We let GDB do the logic for us.  */
>    return 0;
> }
> 

I made a simple example, with gdb.in:
...
catch syscall
continue
delete breakpoints
continue
...

In this case, I run into one PTRACE_SYSCALL (observed using strace).

If I comment out "delete breakpoint", I run into two.

So I think it's possible to disable syscall tracing.

AFAIU the logic is in inf_ptrace_target::resume, were we choose between 
PT_SYSCALL and PT_CONTINUE.

Thanks,
- Tom