From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23605 invoked by alias); 3 May 2006 18:08:57 -0000 Received: (qmail 23597 invoked by uid 22791); 3 May 2006 18:08:56 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 03 May 2006 18:08:54 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FbLmN-0002og-6z; Wed, 03 May 2006 14:08:51 -0400 Date: Wed, 03 May 2006 18:08:00 -0000 From: Daniel Jacobowitz To: Tzu-Chien Chiu Cc: gdb@sourceware.org Subject: Re: remote software breakpoint technical detail Message-ID: <20060503180851.GA10793@nevyn.them.org> Mail-Followup-To: Tzu-Chien Chiu , gdb@sourceware.org References: <4d77c5f20605031043t256b1c05o3d9bb27beef8ed33@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4d77c5f20605031043t256b1c05o3d9bb27beef8ed33@mail.gmail.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00013.txt.bz2 On Thu, May 04, 2006 at 01:43:07AM +0800, Tzu-Chien Chiu wrote: > 5) the processor fetches the breakpoint instruction into the execution > pipeline, and point pc to the next instruction > 6) the breakpoint instruction is decoded, recognized, and the processor > stalls > 7) gdb restores instruction foo > 8) the user issues the single instruction step ('si'), and he expects > instruction foo be executed next, but... > > The question is: > > What value of pc should be expected after step 5 completes? The correct answer is "it depends". In GDB, this is controlled by "set_gdbarch_decr_pc_after_break", and most architectures use whichever setting is more reasonable for their architecture. For yours, it sounds like you want to have GDB decrement the PC after breakpoints. It will write to the PC register itself. > if $pc==foo+4, foo won't be executed but the following instruction, > which is incorrect. > > if $pc==foo, the breakpoint instruction _has been_ fetched into the > execution pipeline at step 5, what makes the cpu to *fetch again* the > instruction restored by gdb at step 7? GDB or the hardware must be > designed to do so? This is an issue whether or not you decrement PC. In the presence of debugger modification of code, something must flush the pipeline. I am not familiar with how other targets do this; I suspect that whatever is mediating between GDB and the target CPU is responsible (e.g. a standalone JTAG box or an independent debug server running on the host). -- Daniel Jacobowitz CodeSourcery