From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id GLYrISqQfGo9uSAAWB0awg (envelope-from ) for ; Wed, 12 Aug 2026 11:24:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1786548266; bh=fpRfjpOBvWxFh7cRU77c9rpHiGaOjJoOV0l0cB3Kteo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=aWWdqbZtk5XaNb0GEqUlMp0sBKirauBQj+X65yE+decTVR/NtMrGHZUkCzQR4P1+m J262kiFS0MpfQPL0Bw9H4/iG/KKFYkM15sssHTocWzqstE8IuOCc9SGRBEsLez40wN 5sm8hGXu1uNiNTXxeS/dFVn7f7PZX7Aee8nNBor4= Received: by simark.ca (Postfix, from userid 112) id 745781E09B; Wed, 12 Aug 2026 11:24:26 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=gFN5+o04; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C18F11E09B for ; Wed, 12 Aug 2026 11:24:25 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9248B4BB24F0 for ; Wed, 12 Aug 2026 15:24:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9248B4BB24F0 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=gFN5+o04 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id BD7054BA23DD for ; Wed, 12 Aug 2026 15:23:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BD7054BA23DD 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 BD7054BA23DD Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786548239; cv=none; b=sztRxL3CY6utfi6DDwBzWDyIp3GMwWl63qOpB1otIhqtJF+oHptkGocbv2Yvle+0W6Ns30feZU+flDlI3J+1oTa6vpELInD55kzLcJFSBZBd+mmyt5cWQLRQaoCMviGOkgwtHkZFHdo4RExN7WS6Wsw1N9rXxPOA0dMZxaL1Vxo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786548239; c=relaxed/simple; bh=fpRfjpOBvWxFh7cRU77c9rpHiGaOjJoOV0l0cB3Kteo=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=lnqtylCOJfLmRUZ84HamuHFX/xhfspcBBTqOwa0EDehvxD3+t6qLnsKEpyMTMyS3m0w46Q6wswu7fH1XgRNRWoh/QDPV1WaHYT8syOLdLK0O9A5bhjCV+Dvi1K964q9osvBdXZ6lUi7cPhPwecjX7TolIXYpS89yuSAzA8Om7Ag= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=gFN5+o04 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BD7054BA23DD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1786548238; bh=fpRfjpOBvWxFh7cRU77c9rpHiGaOjJoOV0l0cB3Kteo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=gFN5+o04/yKyREHHke+nUrzb8xVLOCceo3j34UsSQLesHgrg1o1leq8RgQDqTnhB4 V3m3TbQBV4I53pCPXbgzoGnfvpTcy8XWqXlM0TM6bWG9/UPsjlblLSv82Gmg7Grh+E uE0BvXkEb8pT287/GH9Q/FQxuDz1J7u35t+fqItk= Received: by simark.ca (Postfix) id 99DAD1E09B; Wed, 12 Aug 2026 11:23:58 -0400 (EDT) Message-ID: Date: Wed, 12 Aug 2026 11:23:58 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/1] gdb: avoid conversion of SIGSEGV to SIGTRAP on user breakpoints To: Klaus Gerlicher , gdb-patches@sourceware.org Cc: TankutBaris.Aktemur@amd.com, aburgess@redhat.com References: <20260717074453.253386-1-klaus.gerlicher@intel.com> <20260717074453.253386-2-klaus.gerlicher@intel.com> Content-Language: fr From: Simon Marchi In-Reply-To: <20260717074453.253386-2-klaus.gerlicher@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 7/17/26 3:44 AM, Klaus Gerlicher wrote: > From: "Gerlicher, Klaus" > > GDB converts signals GDB_SIGNAL_ILL, GDB_SIGNAL_SEGV and GDB_SIGNAL_EMT to > GDB_SIGNAL_TRAP if a breakpoint is inserted at the fault location. If, due > to imprecise page fault reporting, a breakpoint is at the same address as > the fault address, this signal would always be reported as GDB_SIGNAL_TRAP. > > Add a new gdbarch function, imprecise_pagefault_reporting, that allows the > signal conversion from GDB_SIGNAL_SEGV to GDB_SIGNAL_TRAP to be skipped for > an architecture. The default is false (conversion enabled), preserving > existing behavior. I'm familiar with the similar feature (precise memory location) for the AMDGPU port, so I had a hunch that it was kind of the same thing, but I had to go read the thread on v1 where you explained it in more details to be really sure. I think that the commit message and perhaps the gdbarch method documentation should expand a bit on what "imprecise page fault reporting" is, including giving a brief example. Here's an example to validate my understanding of it: INSN1 <-- generates a SIGSEGV INSN2 INSN3 <-- breakpoint installed here On such an architecture, if an instruction causes a memory access violation, it's possible for the backend to report the SIGSEGV a few instructions later. Imagine that INSN1 makes an invalid memory access, and then the backend reports the stop at INSN3, where a breakpoint happens to be installed. Then the logic of GDB kicks in where it says: "oh, there is a breakpoint installed at INSN3, so this SIGSEGV must mean that we hit the breakpoint, let me convert that to SIGTRAP". On your architecture that is not true. You know that a breakpoint is never reported by SIGSEGV: if we received a SIGSEGV, it is definitely a SIGSEGV. So you want to disable that conversion logic. Does that sounds right? If so, feel free to use any of this in your commit message / doc. I think that will help people who stumble on that code in the future. Instead of being enabled by default, and then having to disable it in cases like yours, I think it would be nicer if it was disabled by default, and arches had to opt in to enable it. For example, if you know that your arch does report breakpoints as SIGILL (perhaps there is no dedicated breakpoint instruction so inserting an illegal instruction is the only way to reliably make the program stop), then you would implement the gdbarch method to enable that conversion. Unfortunately, that would be a difficult change to do today, because it would require identifying which of the many old arches that GDB supports would need to enable that. > --- > gdb/gdbarch-gen.c | 22 ++++++++++++++++++++++ > gdb/gdbarch-gen.h | 7 +++++++ > gdb/gdbarch_components.py | 12 ++++++++++++ The gdbarch files will need to be regenerated before pushing. With an improved commit message / documentation, I think that this patch will be ok to merge. Simon