From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2610:1c1:1:606c::19:2]) by sourceware.org (Postfix) with ESMTPS id DAC463858D33 for ; Tue, 21 Nov 2023 00:29:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DAC463858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DAC463858D33 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=2610:1c1:1:606c::19:2 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1700526586; cv=pass; b=BGCD3U9Kl1bU8XjuIKuk9PGI472Y91yyCImBL5nrsHl2CwvQy6qjyccBFRb/LhJUaqEEQC7uDoAzlumvgJ551VY/ZfC19TEfdpVe+S8eVdNdo9aEXSDaG8dfZLefH7QBzL6iDOSDaV7dgIEDVymfEA+zzxsqGCN0Bdj8n0x+A7w= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1700526586; c=relaxed/simple; bh=lDo2QcTcwJYSZLjGn8BJ4UED/tQfPLkXdkWc0MeTukc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=dfZvZgOIGcsud5ppjc5fvxfv7pfOnor+Ck2RFGcgbeI3BxG1gTf9keI5N6UqFPAa7FAUGdHOeseYXqMaTuSDHY7UDtJPpt0gk+4dMgS7vmvhGZZMB2D7hs82znR3MqUyaG6329fNxnTmaJZO9tdguHdvdg/IDGr+T2g45BgSse8= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 4SZ4yJ4S5fz4sZQ; Tue, 21 Nov 2023 00:29:44 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SZ4yJ3d81z4X5k; Tue, 21 Nov 2023 00:29:44 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700526584; h=from:from:reply-to:subject:subject: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=vs0amFyKdzeVfko8icdcWZmSB9rZlRG6sFU4T3Hgj38=; b=ZzhgDmCd91hRes9x4av90nb6Vmnnp7g/l1qcyUFrpYqUZD6oGy6Kkq7JArQQvcU1iXOgqm vsP+4RbmCZ5LQb1mqWU+BscSjGgg9CZTmDxh9ewEMNrOcW/Abmk+LizOoMQu0HztWCVIL6 ms3NmnmTc+1ybSC/FJU/zEZVeuHXVjzPo5jPDd6E6wfxJrA66gc4h9VjbRlup98B+bEUCu B5KyHIcIbE/IWhcbipdkM7iuQHMoL0LIE6Nm+iDzq72zUakUTbTQgl8HiMcXPxaH5MXl8z aF6/arYNP3S71bkB2mPu+pZGx5wk1IGJEMiesxVArXKMIcRZfsALPTw9GqIJbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1700526584; h=from:from:reply-to:subject:subject: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=vs0amFyKdzeVfko8icdcWZmSB9rZlRG6sFU4T3Hgj38=; b=xJsd1XUtcob+z3iBjTcqbmobZsPUjAJo62XuVCMYeQovenYs35XhGz/xiab3nUjq48dp9f wQ1k1wqwIaWPUQbNeZhZlDEHkquXx33dTCxGm89MaFfUAzfDBsxjJvo1qAi6eAD8g+QqZ6 lQGtsJIJISYA6DpbcliX9EJvn8Nc6ZAQyxOHL33D0XYAUHiSLZAyBIoNGkZQN7Wxq1bUin skcOQQA+IcqGNrThyFugYNNwLpeqSyiqf8yU8zlT+M0dFj5YiDoAa2/tDJcSqF6fzmXnLt MiTCEjDvyqanRizJBh9XCDkqN8QhQ9utPHmfq6O8xXM6gToRfF2+MFDSBNYKSA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1700526584; a=rsa-sha256; cv=none; b=ohF1goykZENq6TG33Osko4KiMw+m6gBLLVuZ6ayhCh4kp+PY7nnM/DiW6x2Z6sDyDHfswh 8r9IH6OwcQH1Swnfu3YhIZlD+Mh81pd5PFLKm3vdvcq+3uwqZVuYxubN2D2NloH0j/2Mer wCQtQl97O56gkVgPpu6f/6bA9p+S1haYIBkfLXZqzH/ooFRYeq56tpvAHmZbO0qrIZvhy8 Yxuf5YXoLroBq3Bl3UCrNEdg1xyYv5kaqnkOhFhyvfSX8wziCb+4Z1ZuyWSlDNLHvWlp++ H/jofQp9HqarEKBtYs/si9dRv6kEJOB0rbJT5s/ynh2ISpgOCxyDYLyPjHPjfw== Received: from [IPV6:2601:648:8384:fd00:85e6:3fb3:bdd3:e0f9] (unknown [IPv6:2601:648:8384:fd00:85e6:3fb3:bdd3:e0f9]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4SZ4yJ07gmz1460; Tue, 21 Nov 2023 00:29:43 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <63c7905b-784f-4b18-9875-45fc2e3bd3f5@FreeBSD.org> Date: Mon, 20 Nov 2023 16:29:42 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 1/3] [gdb] Call gdbarch_get_syscall_number less often Content-Language: en-US To: Simon Marchi , Tom de Vries , gdb-patches@sourceware.org References: <20231120153749.11072-1-tdevries@suse.de> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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/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 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; } -- John Baldwin