From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5315 invoked by alias); 3 May 2006 18:49:56 -0000 Received: (qmail 5288 invoked by uid 22791); 3 May 2006 18:49:54 -0000 X-Spam-Check-By: sourceware.org Received: from sadr.equallogic.com (HELO sadr.equallogic.com) (66.155.203.134) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 03 May 2006 18:49:43 +0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id k43Infko031670 for ; Wed, 3 May 2006 14:49:41 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id k43Inf3L031665; Wed, 3 May 2006 14:49:41 -0400 Received: from pkoning.equallogic.com ([172.16.1.169]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 May 2006 14:49:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17496.64324.16580.544559@gargle.gargle.HOWL> Date: Wed, 03 May 2006 18:49:00 -0000 From: Paul Koning To: tzuchien.chiu@gmail.com Cc: gdb@sourceware.org Subject: Re: remote software breakpoint technical detail References: <4d77c5f20605031043t256b1c05o3d9bb27beef8ed33@mail.gmail.com> X-Mailer: VM 7.17 under 21.5 (beta23) "daikon" XEmacs Lucid 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/msg00014.txt.bz2 >>>>> "Tzu-Chien" == Tzu-Chien Chiu writes: Tzu-Chien> Hi, all. I'm new to gdb. I have a question on the remote Tzu-Chien> software breakpoint implementation. Either my porting of Tzu-Chien> gdb or there is a bug in our hardware implementation. Tzu-Chien> We have an OpenRISC silicon Tzu-Chien> (http://www.opencores.org). I'm using GDB 5.0. Tzu-Chien> Suppose the instruction cache has been disabled in the Tzu-Chien> very beginning. Tzu-Chien> Here is what I observed: 1) the user set a breakpoint Tzu-Chien> ('b') at instruction foo 2) the user continue ('c') the Tzu-Chien> execution 3) gdb replaces instruction foo with a Tzu-Chien> 'breakpoint instruction", which will stall the processor Tzu-Chien> 4) gdb unstall the processor 5) the processor fetches the Tzu-Chien> breakpoint instruction into the execution pipeline, and Tzu-Chien> point pc to the next instruction 6) the breakpoint Tzu-Chien> instruction is decoded, recognized, and the processor Tzu-Chien> stalls 7) gdb restores instruction foo 8) the user issues Tzu-Chien> the single instruction step ('si'), and he expects Tzu-Chien> instruction foo be executed next, but... Tzu-Chien> The question is: Tzu-Chien> What value of pc should be expected after step 5 Tzu-Chien> completes? Tzu-Chien> if $pc==foo+4, foo won't be executed but the following Tzu-Chien> instruction, which is incorrect. Tzu-Chien> if $pc==foo, the breakpoint instruction _has been_ fetched Tzu-Chien> into the execution pipeline at step 5, what makes the cpu Tzu-Chien> to *fetch again* the instruction restored by gdb at step Tzu-Chien> 7? GDB or the hardware must be designed to do so? The target dependent code in GDB can deal with either foo+4 or foo. Look at the documentation (in gdbint) for DECR_PC_AFTER_BREAK. When GDB tells the target to write to memory (for example, as part of setting or clearing a breakpoint) the target stub, or the target OS, is responsible for dealing with caches, pipelines, etc. For example, most modern machines have separate I and D caches, and I-fetching doesn't look in the D-cache. So a memory write does roughly the following: 1. Store the data 2. Flush the D-cache (forcing all pending writes, or perhaps just the address modified in step 1, to memory) 3. Invalidate the I-cache (forcing I-fetches to go to memory instead). If your processor has a fetch pipeline, and it doesn't re-fetch the instruction at "foo" unless told to do so, then you (the target side code) have to tell it to do that. paul