From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-20645-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 13182 invoked by alias); 8 Feb 2005 16:20:41 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 12887 invoked from network); 8 Feb 2005 16:20:34 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by sourceware.org with SMTP; 8 Feb 2005 16:20:34 -0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j18GKY9I029797
	for <gdb@sources.redhat.com>; Tue, 8 Feb 2005 11:20:34 -0500
Received: from localhost.redhat.com (vpn50-111.rdu.redhat.com [172.16.50.111])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j18GKYO14142;
	Tue, 8 Feb 2005 11:20:34 -0500
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1])
	by localhost.redhat.com (Postfix) with ESMTP id 07DE47D79;
	Tue,  8 Feb 2005 11:20:05 -0500 (EST)
Message-ID: <4208E6B3.7090207@gnu.org>
Date: Tue, 08 Feb 2005 16:22:00 -0000
From: Andrew Cagney <cagney@gnu.org>
User-Agent: Mozilla Thunderbird 0.8 (X11/20041020)
MIME-Version: 1.0
To: Spen <spam@freenetname.co.uk>
Cc: gdb@sources.redhat.com, orjan.friberg@axis.com
Subject: Re: gdb function address
References: <000401c5032f$94ad2a90$10a0bd50@NTHOME>
In-Reply-To: <000401c5032f$94ad2a90$10a0bd50@NTHOME>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2005-02/txt/msg00040.txt.bz2

See: Re: New port: CRISv32
http://sources.redhat.com/ml/gdb-patches/2005-01/msg00243.html

Two things to take on board:
- CRISv32 watchpoints are implemented using register manipulations
- the refactoring (two choices) needed to get this integrated

The ARM highlights the reason why the refactoring is important.  The 
``old way'' was to hard wire specific watchpoint implementation using 
macros (for arm it was wired to the remote.c code) rendering any other 
watchpoint mechanism (such as yours for OCDRemote) useless.

Interested,
Andrew


Spen wrote:
> I am currently using gdb/insight to debug a arm7tdmi via OCDRemote
> GDBServer/TCP.
> The hardware breakpoints can be set as follows:
> monitor set hbreak 0x20000000 - which sets a hardware breakpoint @
> address 0x20000000.
> 
> This method only gives access to a single breakpoint, the other used by
> ocdremote for stepping etc.
> 
> The user command below is another method and gives access to both
> hardware breakpoints
> 
> define ibreak
> monitor reg w$arg0av = $arg1
> monitor reg w$arg0am = 1
> monitor reg w$arg0dv = 0
> monitor reg w$arg0dm = 0xFFFFFFFF
> monitor reg w$arg0cv = 0x100
> monitor reg w$arg0cm = 0xFFFFFEF7
> end
> 
> ibreak 0 0x20000000 - set breakpoint zero @ 0x20000000
> 
> The drawback is that the breakpoint address needs to be known, is there
> any way to get behaiour similar to the standard break/hbreak commands,
> ie. break main. And resolve the function name into an address ?
> 
> Many Thanks
> Spencer Oliver
> 
>