This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH/RFC] Simplify adjust_pc_after_break?
- From: Daniel Jacobowitz <drow at false dot org>
- To: Mark Kettenis <kettenis at chello dot nl>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sat, 26 Mar 2005 17:23:32 -0500
- Subject: Re: [PATCH/RFC] Simplify adjust_pc_after_break?
- References: <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