From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31629 invoked by alias); 13 Feb 2003 00:55:16 -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 31618 invoked from network); 13 Feb 2003 00:55:15 -0000 Received: from unknown (HELO mta03bw.bigpond.com) (139.134.6.86) by 172.16.49.205 with SMTP; 13 Feb 2003 00:55:15 -0000 Received: from neurizon.net ([144.135.24.87]) by mta03bw.bigpond.com (Netscape Messaging Server 4.15 mta03bw Jul 16 2002 22:47:55) with SMTP id HA82K000.A9H for ; Thu, 13 Feb 2003 10:55:12 +1000 Received: from CPE-203-51-231-207.qld.bigpond.net.au ([203.51.231.207]) by bwmam07.mailsvc.email.bigpond.com(MailRouter V3.0n 56/441071); 13 Feb 2003 10:55:11 Message-ID: <3E4AED96.1000604@neurizon.net> Date: Thu, 13 Feb 2003 00:55:00 -0000 From: Steven Johnson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb Subject: Re: ARM7, remote GDB, Software Breakpoints References: <200302122117.58218.tmohr@s.netic.de> <20030212204915.GA575@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00206.txt.bz2 > > >This was touched recently. The remote logic decides that 0 hardware >breakpoint resources are available; I don't remember if the patch to >fix it was checked in. You might want to ask Andrew if he remembers >the problem. > >There's probably something in the host gdb you have to set. > > > Very recently, I posted a patch to the gdb patches list, that allows the user to set the number of hardware breakpoints and watchpoints their target supports by way of commands within GDB. I never received any feedback for it, so I don't know what status it is. I also tackeled it defferently. In my stub, when I set a breakpoint I Favour Hardware breakpints (because I think they are better). So if gdb tells the stub to set a breakpoint, regardless of type, then I set hardware breakpoints until they are exhausted, and then I fall back to software breakpoints. If GDB explicitly tells my stub to set hardware breakpoints it sets these first. (And then falls back to software). So basically I prioritise breakpoints and use what GDB tells the stub as a hint, so: 1. Set GDB Requested Hardware Breakpoints first. 2. Set GDB Requested Software Breakpoints second. 3. Until all hardware breakpoints are consumed, set hardware breakpoints. 4. When all hardware breakpoints are consumed revert to software breakpoints. This works really well for me. The only thing the user has to be carefull of is not setting too many breakpoints when debugging in ROM. But if your not carefull enough to do this, your probably not capable of debugging ROM based code anyway :) Steven Johnson