From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id EBF73385840D for ; Mon, 20 Nov 2023 15:35:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EBF73385840D 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 EBF73385840D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.220.28 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700494558; cv=none; b=BSv0lPR934W0fu/YOGs3IhAQqF47Y+S62Qwug9istwA+P5ohOePU03pU42DbwV7oVTvJqDziiIpTjLMQLukarkuCIDgH8JPIFIBUjcWeJG2sZLxyI3hEMwz5PafWbWrUbERC0Om8/eRzdxlwMgz7tsSgNACDxb2/KbDcOByv38k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700494558; c=relaxed/simple; bh=Fvrh84aGVQAa6+47/RoOeGnNAqloQ96I7nhK6k58p9g=; h=DKIM-Signature:DKIM-Signature:From:To:Subject:Date:Message-Id: MIME-Version; b=XXD+hbEAbeYLTQhXFKR0IUspTJ5i8W2NkFuR0GwTaUEye//RXb5JMiv+WpGlKi7iY9d67aZSmiKo8uU/Ja3nCbrtb83wyVc21toq7r7Bg3e3cvTiIrCUT9dHS0mKLZrzpyADAxOXB+0qYLCozzSGkk6dHb/xMGw92bzmB/8ZASg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id DFC2D218F8 for ; Mon, 20 Nov 2023 15:35:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1700494555; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=OfneYs9E0yGTbrqFLrYG3lldDn8SX0wX9tSZMf/bSJU=; b=u6d3GQTPnb9fURLFjwo8F+QzBM4hV1m9rnnxDZBvlNL3U5gcvKHVfVfa83HOGTxqmIwCJt 8BYBkvrkutI1A0IIlVaHeIFhA3LNDGd3cDddsj8h8Ik6eYEjt/y0nflDKjVNYmtdvB2rwA fhKy0wc2WLMHj0ZqrioZlLZjqmlJRhc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1700494555; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=OfneYs9E0yGTbrqFLrYG3lldDn8SX0wX9tSZMf/bSJU=; b=0r+q2SI2oy2gMaFCjRG5B7xj5gpBhcPvBsX0wXVA+e0RBxF0m0Bsa2N73ClMVQy47v+Zu0 SU3om2IR9RuUUqBw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id C284C134AD for ; Mon, 20 Nov 2023 15:35:55 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id HXJlLtt8W2WDTQAAMHmgww (envelope-from ) for ; Mon, 20 Nov 2023 15:35:55 +0000 From: Tom de Vries To: gdb-patches@sourceware.org Subject: [RFC 1/3] [gdb] Call gdbarch_get_syscall_number less often Date: Mon, 20 Nov 2023 16:37:47 +0100 Message-Id: <20231120153749.11072-1-tdevries@suse.de> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Authentication-Results: smtp-out1.suse.de; none X-Spam-Level: X-Spam-Score: 0.70 X-Spamd-Result: default: False [0.70 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; R_MISSING_CHARSET(2.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[gdb-patches@sourceware.org]; BROKEN_CONTENT_TYPE(1.50)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_NONE(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-0.995]; MID_CONTAINS_FROM(1.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; BAYES_HAM(-3.00)[100.00%] X-Spam-Status: No, score=-12.2 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: 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). 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. PR tdep/28623 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28623 --- gdb/linux-nat.c | 35 +++++++++++++++++++++--- gdb/linux-nat.h | 3 ++ gdb/testsuite/gdb.base/catch-syscall.exp | 8 +----- 3 files changed, 35 insertions(+), 11 deletions(-) diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c index d3e9560c2fc..efc5053cf85 100644 --- a/gdb/linux-nat.c +++ b/gdb/linux-nat.c @@ -1762,7 +1762,25 @@ 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); - int syscall_number = (int) gdbarch_get_syscall_number (gdbarch, thread); + + enum target_waitkind new_syscall_state + = (lp->syscall_state == TARGET_WAITKIND_SYSCALL_ENTRY + ? TARGET_WAITKIND_SYSCALL_RETURN + : TARGET_WAITKIND_SYSCALL_ENTRY); + + int syscall_number; + if (new_syscall_state == TARGET_WAITKIND_SYSCALL_RETURN + && lp->syscall_number != -1) + { + /* 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. */ + syscall_number = lp->syscall_number; + } + else + { + syscall_number = (int) gdbarch_get_syscall_number (gdbarch, thread); + } if (stopping) { @@ -1801,9 +1819,18 @@ linux_handle_syscall_trap (struct lwp_info *lp, int stopping) the user could install a new catchpoint for this syscall between syscall enter/return, and we'll need to know to report a syscall return if that happens. */ - lp->syscall_state = (lp->syscall_state == TARGET_WAITKIND_SYSCALL_ENTRY - ? TARGET_WAITKIND_SYSCALL_RETURN - : TARGET_WAITKIND_SYSCALL_ENTRY); + lp->syscall_state = new_syscall_state; + + if (lp->syscall_state == TARGET_WAITKIND_SYSCALL_ENTRY) + { + /* Save to use in TARGET_WAITKIND_SYSCALL_RETURN. */ + lp->syscall_number = syscall_number; + } + else + { + /* Reset to prevent stale values. */ + lp->syscall_number = -1; + } if (catch_syscall_enabled ()) { diff --git a/gdb/linux-nat.h b/gdb/linux-nat.h index cce8bb3ddcc..d53bd8bda5b 100644 --- a/gdb/linux-nat.h +++ b/gdb/linux-nat.h @@ -277,6 +277,9 @@ struct lwp_info : intrusive_list_node - TARGET_WAITKIND_SYSCALL_RETURN */ enum target_waitkind syscall_state; + /* Syscall number corresponding to syscall_state. */ + int syscall_number = -1; + /* The processor core this LWP was last seen on. */ int core = -1; diff --git a/gdb/testsuite/gdb.base/catch-syscall.exp b/gdb/testsuite/gdb.base/catch-syscall.exp index 0588cb35d87..d8ea466cf00 100644 --- a/gdb/testsuite/gdb.base/catch-syscall.exp +++ b/gdb/testsuite/gdb.base/catch-syscall.exp @@ -134,13 +134,7 @@ proc check_return_from_syscall { syscall { pattern "" } } { return 1 } -re -wrap ".*Breakpoint $decimal, main .*" { - # On Powerpc the kernel does not report the returned from - # syscall as expected by the test. GDB bugzilla 28623. - if { [istarget "powerpc64*-linux*"] } { - xfail $thistest - } else { - fail $thistest - } + fail $thistest return 0 } } base-commit: fdb4c2e02e6600b51f38a60cd70882887007cbdf -- 2.35.3