From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12001 invoked by alias); 26 Mar 2005 22:34:12 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11971 invoked from network); 26 Mar 2005 22:34:07 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 26 Mar 2005 22:34:07 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DFJrm-0000II-V8; Sat, 26 Mar 2005 17:34:51 -0500 Date: Sat, 26 Mar 2005 22:34:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFC] Simplify adjust_pc_after_break? Message-ID: <20050326223450.GB385@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sources.redhat.com References: <200405162328.i4GNSaNS000789@elgar.kettenis.dyndns.org> <20050326222332.GA385@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050326222332.GA385@nevyn.them.org> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00350.txt.bz2 [Trying again with Mark's current email.] 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