From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18196 invoked by alias); 14 Feb 2003 16:28:45 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18186 invoked from network); 14 Feb 2003 16:28:44 -0000 Received: from unknown (HELO hotmail.com) (64.4.9.116) by 172.16.49.205 with SMTP; 14 Feb 2003 16:28:44 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 14 Feb 2003 08:28:43 -0800 Received: from 212.153.190.4 by lw9fd.law9.hotmail.msn.com with HTTP; Fri, 14 Feb 2003 16:28:43 GMT X-Originating-IP: [212.153.190.4] From: "Jan Hoogerbrugge" To: msalter@redhat.com, ac131313@redhat.com Cc: gdb@sources.redhat.com Bcc: Subject: Re: Remote breakpoint problem Date: Fri, 14 Feb 2003 16:28:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Feb 2003 16:28:43.0457 (UTC) FILETIME=[23E16B10:01C2D446] X-SW-Source: 2003-02/txt/msg00239.txt.bz2 >From: Mark Salter >To: ac131313@redhat.com > >>>>> Andrew Cagney writes: > > >> Hi, > >> > >> I am porting gdb to a new target processor were remote debugging is >used. I have a problem with breakpoints. When I place a breakpoint on foo >followed by a continue I see the following communication between gdb and >the stub on the other side: > >> > >> - the instruction at foo is saved > >> - foo is replaced by a breakpoint instruction > >> - gdb sends a continue command > >> - the stub reports the breakpoint hit (signal = 5, pc = foo) > >> - gdb replaces the code at foo with the saved instruction > >> - gdb sends a step instruction command > >> - tbe stub reports again a breakpoint hit at foo (signal = 5, pc = foo) > > > Shouldn't this stop beyond foo? > >I wonder if the stub is flushing the icache after gdb puts the >saved instruction back... Caches are properly syncronisched. The respone of the remote target and its stub is correct as far as I can see. It is gdb that issues a continue command to the stub after hitting the breakpoint and single stepping the instruction on which teh breakpoint was placed. This is what gccint.texinfo says: >Software breakpoints require @value{GDBN} to do somewhat more work. >The basic theory is that @value{GDBN} will replace a program >instruction with a trap, illegal divide, or some other instruction >that will cause an exception, and then when it's encountered, >@value{GDBN} will take the exception and stop the program. When the >user says to continue, @value{GDBN} will restore the original >instruction, single-step, re-insert the trap, and continue on. Cheers, Jan _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963