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