Re: [PATCH 1/3] [gdb/tdep] Add syscall number cache

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

On 11/24/23 22:09, Simon Marchi wrote:
> On 11/22/23 04:10, 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.
>>
>> We can address this issue somewhat by translating events into syscalls.  A
>> followup patch in this series use this approach (though not for vfork).
>>
>> PR tdep/28623
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28623
>> ---
>>   gdb/linux-nat.c                          | 45 ++++++++++++++++++++++--
>>   gdb/linux-nat.h                          |  3 ++
>>   gdb/testsuite/gdb.base/catch-syscall.exp |  8 +----
>>   3 files changed, 46 insertions(+), 10 deletions(-)
>>
>> diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c
>> index 7b0562cf89b..ab6eadd557d 100644
>> --- a/gdb/linux-nat.c
>> +++ b/gdb/linux-nat.c
>> @@ -1508,6 +1508,17 @@ linux_resume_one_lwp_throw (struct lwp_info *lp, int step,
>>     else
>>       lp->stop_pc = 0;
>>   
>> +  if (catch_syscall_enabled () > 0)
>> +    {
>> +      /* Function inf_ptrace_target::resume uses PT_SYSCALL.  */
>> +    }
>> +  else
>> +    {
>> +      /* Function inf_ptrace_target::resume uses PT_CONTINUE.
>> +	 Invalidate syscall_number cache.  */
>> +      lp->syscall_number = -1;
>> +    }
>> +
>>     linux_target->low_prepare_to_resume (lp);
>>     linux_target->low_resume (lp->ptid, step, signo);
>>   
>> @@ -1762,7 +1773,26 @@ linux_handle_syscall_trap (struct lwp_info *lp, int stopping)
>>     struct target_waitstatus *ourstatus = &lp->waitstatus;
>>     struct gdbarch *gdbarch = target_thread_architecture (lp->ptid);
>>     thread_info *thread = linux_target->find_thread (lp->ptid);
>> +
>> +  enum target_waitkind new_syscall_state
>> +    = (lp->syscall_state == TARGET_WAITKIND_SYSCALL_ENTRY
>> +       ? TARGET_WAITKIND_SYSCALL_RETURN
>> +       : TARGET_WAITKIND_SYSCALL_ENTRY);
>> +
>>     int syscall_number = (int) gdbarch_get_syscall_number (gdbarch, thread);
>> +  if (new_syscall_state == TARGET_WAITKIND_SYSCALL_RETURN
>> +      && lp->syscall_number != -1
>> +      && lp->syscall_number != syscall_number)
>> +    {
>> +      /* Calling gdbarch_get_syscall_number for TARGET_WAITKIND_SYSCALL_RETURN
>> +	 is unreliable on some targets for some syscalls, use the syscall
>> +	 detected at TARGET_WAITKIND_SYSCALL_ENTRY instead.  */
>> +      linux_nat_debug_printf
>> +	(_("Using syscall number %d supplied by syscall_number cache instead"
>> +	   " of %d supplied by architecture hook"),
>> +	       lp->syscall_number, syscall_number);
>> +      syscall_number = lp->syscall_number;
>> +    }
> 
> If we're going to use lp->syscall_number (if it is not -1) and it
> disagrees with gdbarch_get_syscall_number, what's the point in calling
> gdbarch_get_syscall_number in the first place?

The debug printf that notes the override of gdbarch_get_syscall_number 
by the cached syscall number.

> Should the logic be:
> 
>    if (new_syscall_state == TARGET_WAITKIND_SYSCALL_RETURN
>        && lp->syscall_number != -1)
>      // use lp->syscall_number
>    else
>      // call gdbarch_get_syscall_number
> 
> ?

If we don't care about that particular type of debug printf, then yes.

Thanks,
- Tom