From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id AC9A33858D38 for ; Tue, 21 Nov 2023 21:19:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AC9A33858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AC9A33858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700601580; cv=none; b=t9psAv20YNZez8BBCTE8Hey+rwzyuf9c5Z+OfIwgR7iq/inYo7lXcEEvlZ+gJeMFGlmYby4tlLNArPbSGAOAnRbBDrlxXmbUdzFnO+qdm5h/qpFJuAN641KKgUkNnjIXETcCPbIw37+ulEtvvz4KQxtHumHdGTuuKJqROzDp5xc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700601580; c=relaxed/simple; bh=8iAAUWJhGDuomZGw/+eXfqA1EqmyTt5c0QxxzoNvUQw=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=B9v/ateCsiqsH9eS1HgW+alVh8i6oGj1Bov6X7Z5kWAGguGw6cG9RPbiB3WqTFgUf68VIjIt5JdxL3kZELRdfMQC338Cvk9KjjkeM6q5YS3ZWzbJotErLYktRH/LUmqdqQIshR6fkO4lr+cRuwXcXIa+JvBJE+x2076eWNs288k= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1700601576; bh=8iAAUWJhGDuomZGw/+eXfqA1EqmyTt5c0QxxzoNvUQw=; h=Date:Subject:To:References:From:In-Reply-To:From; b=vQumi1XmBoW5zBQJV/q3m5sK91BPLLDB6B9Zv/EmAtWeDh4i5YXFilvUoK+Fbc0go UhdfAkCU5UFzDqIKysjS4VOtJufCXQ/3Sojg9oJrbGEoHqK71zSBdETPmyPGo3LxMB 1Q4dZEKvv0jMU0BlXYaVmvqC5pY71nMdb4QoIWfI= Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 35ACA1E091; Tue, 21 Nov 2023 16:19:36 -0500 (EST) Message-ID: <5f90118c-c99f-44df-9a9a-9ab291430797@simark.ca> Date: Tue, 21 Nov 2023 16:19:35 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC 1/3] [gdb] Call gdbarch_get_syscall_number less often Content-Language: fr To: John Baldwin , Tom de Vries , gdb-patches@sourceware.org References: <20231120153749.11072-1-tdevries@suse.de> <0297df07-9331-4911-becc-e7aba0e92a7b@suse.de> <270c0418-e216-415a-b40b-d100983cb6e0@FreeBSD.org> From: Simon Marchi In-Reply-To: <270c0418-e216-415a-b40b-d100983cb6e0@FreeBSD.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,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/21/23 13:03, John Baldwin wrote: > I think you can use linux_nat_target::set_syscall_catchpoint to do the > invalidation. From my reading it is called each time a syscall catchpoint > is added or removed, and needed is set to false if there are no more > catchpoints (so syscall catches are disabled). I think that means > you could do something like: > > linux_nat_target::set_syscall_catchpoint () > { > if (!needed) > iterate_over_lwps (ptid_t (pid), [] (struct lwp_info *lp) > { > lp->syscall_number = -1; > }); > } What about this corner case of a corner case: 1. you have a syscall catchpoint, you hit it (the syscall entry) 2. you delete the syscall catchpoint 3. you create a syscall catchpoint again 4. you continue, expecting to hit the syscall exit Will step 2 cause set_syscall_catchpoint to be called, and will we therefore lose the information that would have been useful at step 4? Simon