From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by sourceware.org (Postfix) with ESMTPS id A93DF3858D39 for ; Fri, 24 Nov 2023 22:19:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A93DF3858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A93DF3858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700864392; cv=none; b=uaWXFr4rUdqZBWHnyoSqv1dQjljfUw30yZuk5kErixQejYkdUGWsBnqETTPrnsXVqp0bftPWnwpbhYV3y902q7OzyJlxwshsjHflF3Q+lEb8mqGNlLLuzWjU6T/CcmEDQ8DRasUtaP+d04LYCMwg/UVDHIf+ZrbJYdigNkjrAfE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700864392; c=relaxed/simple; bh=8SyKtrzopk1+/HWErso1mpP+NNbM4o43An8avf/rti4=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=aeZkDoFTpPoX1pK6y8nqfpFVAIQNb0wNtzvOP23sf03MCTAdmm8R0yKfReys/ss3vdhftJO1pdjnf73T94PGdggzr8sntR87+6WHdhgGVIeWnWXDmlRB9wMVD+p86nt7i1xjZS91G3tYehEoF1PXi3bvJIaHyW4TJ+Bdsi1azzk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 88AD21FB8D; Fri, 24 Nov 2023 22:19:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1700864387; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C5X2rCovtfzFmWqTMJgKawpuRj0+1dm9ZmDHERxHyKI=; b=fYj6DeI5I/pJ8fcHHVE56tGA7f377uZxNYA4AYnFbCVz8fyDG/3DVYYDEv5/x1Z+BLyV7L q/ha0CJHxr3NmwP7mRQ8E6M5u7SufuwGLzq1QbXXY7hmAXeLUx+F4LL6xXshhrUTcBPXQW dO6dUfQWlpGNj633+VNIhXgD9hHwFns= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1700864387; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C5X2rCovtfzFmWqTMJgKawpuRj0+1dm9ZmDHERxHyKI=; b=8zDn8DSg/cnAfmd34r+1eh3Mp53k/SmtZYkkOU+18UoZT+O0qQQPPSertcTtvaI9lj7c+u FjdKseFs6a7VunBw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 6EB5113A9F; Fri, 24 Nov 2023 22:19:47 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id hDzoF4MhYWViRQAAD6G6ig (envelope-from ); Fri, 24 Nov 2023 22:19:47 +0000 Message-ID: Date: Fri, 24 Nov 2023 23:19:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] [gdb/tdep] Add syscall number cache Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20231122091020.8640-1-tdevries@suse.de> From: Tom de Vries In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: smtp-out2.suse.de; none X-Spam-Score: 3.39 X-Spamd-Result: default: False [3.39 / 50.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; BAYES_HAM(-3.00)[100.00%]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(2.98)[0.995]; MIME_GOOD(-0.10)[text/plain]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_SPAM_LONG(3.50)[1.000]; DBL_BLOCKED_OPENRESOLVER(0.00)[sourceware.org:url]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_TLS_ALL(0.00)[] X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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