From: Daniel Jacobowitz <drow@false.org>
To: Mark Kettenis <kettenis@chello.nl>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH/RFC] Simplify adjust_pc_after_break?
Date: Sat, 26 Mar 2005 22:22:00 -0000 [thread overview]
Message-ID: <20050326222332.GA385@nevyn.them.org> (raw)
In-Reply-To: <200405162328.i4GNSaNS000789@elgar.kettenis.dyndns.org>
On Mon, May 17, 2004 at 01:28:36AM +0200, Mark Kettenis wrote:
> The signal tests are failing horribly on Solaris x86. The problem is
> that upon hitting a breakpoint in the signal handler, we don't
> properly back up the PC.
Hi Mark,
While sorting through old mail I found this message. Andrew explained
why your patch was wrong; has this been fixed some other way, or are we
still broken on Solaris x86?
> The problem here seems to stem from the fact that we were
> single-stepping when the signal arrived. The signal takes us out of
> the single-stepping range, and when we hit the breakpoint, we're atan
> address that's miles away from PREV_PC. As a result
> adjust_pc_after_break decides that there is no reason to back up the
> PC.
>
> Why don't we see this on other i386 targets? There is some code in
> handle_inferior_event() that notices when a signal takes us out of the
> single-stepping range. However, procfs(4) has this nice feature that
> you can tell it what signals to report. We tell it to only report
> signals that we're interested in. In this particular case we're not
> interested in the SIGALRM, so GDB never sees it, and the code in
> handle_inferior_event() is never executed.
>
> Looking at adjust_pc_after_break() I couldn't figure out why we're
> trying do. I could imagine that we shouldn't back up the PC if a
> breakpoint and single-step coalesce, but that's exactly the condition
> where we *do* back up the PC. So why not simplify things and just
> back up the PC if we detect an inserted breakpoint?
>
> The attached patch works for me on Solaris x86 and various other i386
> and amd64 targets. But I'm probably overlooking something.
--
Daniel Jacobowitz
CodeSourcery, LLC
next prev parent reply other threads:[~2005-03-26 22:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-16 23:28 Mark Kettenis
2004-05-17 14:23 ` Andrew Cagney
2004-05-17 15:07 ` Mark Kettenis
2005-03-26 22:22 ` Daniel Jacobowitz [this message]
2005-03-26 22:34 ` Daniel Jacobowitz
2005-03-26 22:37 ` Mark Kettenis
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=20050326222332.GA385@nevyn.them.org \
--to=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@chello.nl \
/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