Re: [PATCH v4 1/1] gdb: avoid conversion of SIGSEGV to SIGTRAP on user breakpoints

Simon Marchi <[email protected]>
Newsgroups gmane.comp.gdb.patches
Message-ID <[email protected]>
On 7/17/26 3:44 AM, Klaus Gerlicher wrote:
> From: "Gerlicher, Klaus" <[email protected]>
> 
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.