Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Klaus Gerlicher <klaus.gerlicher@intel.com>, gdb-patches@sourceware.org
Cc: TankutBaris.Aktemur@amd.com, aburgess@redhat.com
Subject: Re: [PATCH v4 1/1] gdb: avoid conversion of SIGSEGV to SIGTRAP on user breakpoints
Date: Wed, 12 Aug 2026 11:23:58 -0400	[thread overview]
Message-ID: <d7942070-dcb6-4a5a-ac88-2498e3e44135@simark.ca> (raw)
In-Reply-To: <20260717074453.253386-2-klaus.gerlicher@intel.com>

On 7/17/26 3:44 AM, Klaus Gerlicher wrote:
> From: "Gerlicher, Klaus" <klaus.gerlicher@intel.com>
> 
> 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

  parent reply	other threads:[~2026-08-12 15:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13  8:19 [PATCH v3 " Aktemur, Baris
2026-05-19 10:29 ` Gerlicher, Klaus
2026-07-07  6:35   ` Aktemur, Baris
2026-07-17  7:44     ` [PATCH v4 0/1] " Klaus Gerlicher
2026-07-17  7:44       ` [PATCH v4 1/1] " Klaus Gerlicher
2026-07-17  9:16         ` Aktemur, Baris
2026-07-17 13:25           ` Gerlicher, Klaus
2026-07-28  8:49             ` Aktemur, Baris
2026-08-12 15:23         ` Simon Marchi [this message]
2026-07-17  7:46     ` [PATCH v3 " Gerlicher, Klaus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d7942070-dcb6-4a5a-ac88-2498e3e44135@simark.ca \
    --to=simark@simark.ca \
    --cc=TankutBaris.Aktemur@amd.com \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=klaus.gerlicher@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox