From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29156 invoked by alias); 10 Feb 2009 19:05:46 -0000 Received: (qmail 29145 invoked by uid 22791); 10 Feb 2009 19:05:45 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Feb 2009 19:05:39 +0000 Received: (qmail 19784 invoked from network); 10 Feb 2009 19:05:33 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Feb 2009 19:05:33 -0000 From: Pedro Alves To: Mark Kettenis Subject: Re: Regression Date: Tue, 10 Feb 2009 19:05:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb@sourceware.org, drow@false.org References: <200902101517.n1AFH7YP000549@brahms.sibelius.xs4all.nl> <200902101800.35832.pedro@codesourcery.com> <200902101839.n1AId4Mb031903@brahms.sibelius.xs4all.nl> In-Reply-To: <200902101839.n1AId4Mb031903@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902101905.37812.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00087.txt.bz2 On Tuesday 10 February 2009 18:39:04, Mark Kettenis wrote: > I've looked at the PR mentioned in the commi message, and I don't > quite understand how the change to the signal command has anything to > do with that. Before Daniel's Daniel's patch, `signal_command' called `proceed' like so: + proceed (oursig == TARGET_SIGNAL_0 ? (CORE_ADDR) -1 : stop_pc, oursig, 0); For a signal != TARGET_SIGNAL_0, say signal FOO, that's effectivelly this: proceed (stop_pc, oursig, 0); void proceed (CORE_ADDR addr, enum target_signal siggnal, int step) { (...) if (addr == (CORE_ADDR) -1) { if (pc == stop_pc && breakpoint_here_p (pc) && execution_direction != EXEC_REVERSE) /* There is a breakpoint at the address we will resume at, step one instruction before inserting breakpoints so that we do not stop right away (and report a second hit at this breakpoint). Note, we don't do this in reverse, because we won't actually be executing the breakpoint insn anyway. We'll be (un-)executing the previous instruction. */ oneproc = 1; else if (gdbarch_single_step_through_delay_p (gdbarch) && gdbarch_single_step_through_delay (gdbarch, get_current_frame ())) /* We stepped onto an instruction that needs to be stepped again before re-inserting the breakpoint, do so. */ oneproc = 1; } else { regcache_write_pc (regcache, addr); } (...) This messed with syscall restarting on linux, since it was writing the PC. Notice that the (addr != (CORE_ADDR) -1) code path doesn't set `oneproc', hence, ends up *not* removing breakpoints, and *not* single-stepping, even if we were stopped at a breakpoint. That is what I call the "jump" behaviour --- a jump to $PC hits a breakpoint at $PC. After Daniel's change, signal_command does this unconditionaly: proceed ((CORE_ADDR) -1, oursig, 0); Which means we now go through the "(addr == (CORE_ADDR) -1)" branch above. This avoided the regcache_write_pc call. But, it also sets `oneproc' because in this case, there's a breakpoint at stop_pc, and PC is still at stop_pc. That will make us remove breakpoints from the inferior, and call `resume' with step=1. The part that's breakpoint the BSDs is the fact that we now remove breakpoints from the inferior. -- Pedro Alves