From: "Gerlicher, Klaus" <klaus.gerlicher@intel.com>
To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
"aburgess@redhat.com" <aburgess@redhat.com>
Subject: [PING V2][PATCH v3 0/1] gdb: avoid conversion of SIGSEGV to SIGTRAP on user breakpoints
Date: Wed, 14 May 2025 12:01:04 +0000 [thread overview]
Message-ID: <SN7PR11MB7091B4B3102CA8DC62D90466E891A@SN7PR11MB7091.namprd11.prod.outlook.com> (raw)
In-Reply-To: <SN7PR11MB70915E39D3461F9030C5364CE8802@SN7PR11MB7091.namprd11.prod.outlook.com>
Hi,
Kindly pinging.
Thanks
Klaus
> -----Original Message-----
> From: Gerlicher, Klaus
> Sent: Tuesday, April 29, 2025 9:47 AM
> To: gdb-patches@sourceware.org; aburgess@redhat.com
> Subject: RE: [PATCH v3 0/1] gdb: avoid conversion of SIGSEGV to SIGTRAP on
> user breakpoints
>
> Hi,
>
> Kindly pinging.
>
> I think I've lost a bit of momentum here since last November but I had
> implemented the gdbarch approach here.
>
> Thanks
> Klaus
>
>
> > -----Original Message-----
> > From: Klaus Gerlicher <klaus.gerlicher@intel.com>
> > Sent: Wednesday, November 27, 2024 12:02 PM
> > To: gdb-patches@sourceware.org; aburgess@redhat.com
> > Subject: [PATCH v3 0/1] gdb: avoid conversion of SIGSEGV to SIGTRAP on
> user
> > breakpoints
> >
> > Hi Andrew,
> >
> > thanks for the feedback.
> >
> > You replied:
> >
> > > But, I wonder if there's a different approach that could be used?
> > >
> > > I assume that your out of tree architecture with these imprecise page
> > > faults has a new gdbarch to represent it.
> > >
> > > You are limiting the SIGSEGV -> SIGTRAP conversion because, I assume,
> > > you've hit cases where a SIGSEGV occurs and then your target has run on
> > > and reported the stop at the address of a user breakpoint. But all
> > > you're really doing is reducing the scope for errors. It could be the
> > > case that the SIGSEGV is reported at the site of an internal breakpoint,
> > > and then you'll still have issues.
> > >
> > > So what if, instead, you added a new gdbarch method, something like:
> > >
> > > bool gdbarch_has_imprecise_page_faults (struct gdbarch *gdbarch);
> > >
> > > The default for this, and for all currently in-tree targets, would be to
> > > return true. For your target this will return false.
> > >
> > > Then in this code we would do:
> > >
> > > if (ecs->ws.kind () == TARGET_WAITKIND_STOPPED
> > > && (ecs->ws.sig () == GDB_SIGNAL_ILL
> > > || (ecs->ws.sig () == GDB_SIGNAL_SEGV
> > > !gdbarch_has_imprecise_page_faults (gdbarch))
> > > || ecs->ws.sig () == GDB_SIGNAL_EMT))
> > >
> > > How does this approach sound?
> >
> > I think for now this would be a viable solution and I implemented it in the V3
> > patch.
> >
> > However, we had a little discussion internally and we were wondering if this
> > now
> > feels more like a workaround in a workaround.
> >
> > It seems to me that the conversion of any of these signals should really be
> > only done for a specific target. Even though the SIG_ILL and SIG_EMT
> > conversions obviously have no side effects for most targets, I would think
> > these should be avoided.
> >
> > Do you think there's a way to limit these more specifically or are we unsure
> > which targets actually need these? Maybe some of the users are already
> > obsolete?
> >
> > I would assume it would be difficult to limit to a specific target when we used
> > the remote target since we would then have to update GDB server to also
> > support
> > this.
> >
> > I'm of course fine if we fix it with the architecture method but maybe others
> > would disagree?
> >
> > Thanks
> > Klaus
> >
> > Gerlicher, Klaus (1):
> > gdb: avoid conversion of SIGSEGV to SIGTRAP on user breakpoints
> >
> > gdb/gdbarch-gen.c | 22 ++++++++++++++++++++++
> > gdb/gdbarch-gen.h | 7 +++++++
> > gdb/gdbarch_components.py | 12 ++++++++++++
> > gdb/infrun.c | 4 +++-
> > 4 files changed, 44 insertions(+), 1 deletion(-)
> >
> > --
> > 2.34.1
> >
> > Intel Deutschland GmbH
> > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> > Tel: +49 89 99 8853-0, www.intel.de
> > Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
> > Chairperson of the Supervisory Board: Nicole Lau
> > Registered Office: Munich
> > Commercial Register: Amtsgericht Muenchen HRB 186928
> >
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
prev parent reply other threads:[~2025-05-14 12:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-27 11:01 [PATCH " Klaus Gerlicher
2024-11-27 11:01 ` [PATCH v3 1/1] " Klaus Gerlicher
2025-05-16 11:07 ` Andrew Burgess
2025-04-29 7:47 ` [PATCH v3 0/1] " Gerlicher, Klaus
2025-05-14 12:01 ` Gerlicher, Klaus [this message]
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=SN7PR11MB7091B4B3102CA8DC62D90466E891A@SN7PR11MB7091.namprd11.prod.outlook.com \
--to=klaus.gerlicher@intel.com \
--cc=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
/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