From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7455 invoked by alias); 9 Jun 2003 15:07:14 -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 7410 invoked from network); 9 Jun 2003 15:07:13 -0000 Received: from unknown (HELO sun.netezza.com) (209.113.240.37) by sources.redhat.com with SMTP; 9 Jun 2003 15:07:13 -0000 Received: from astral (host20 [192.168.0.20]) by sun.netezza.com (8.12.9+Sun/8.12.9) with SMTP id h59F7CTA011698; Mon, 9 Jun 2003 11:07:12 -0400 (EDT) Message-ID: <012a01c32e98$ce0beaa0$1400a8c0@astral> Reply-To: "John S. Yates, Jr." From: "John S. Yates, Jr." To: "Andrew Cagney" Cc: "gdb" References: <005d01c32a0f$86f44fa0$1400a8c0@astral> <3EE38BB8.1060904@redhat.com> Subject: Re: supporting hw break/watch for embedded ppc Date: Mon, 09 Jun 2003 15:07:00 -0000 Organization: Netezza Corporation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-06/txt/msg00107.txt.bz2 > > I have an mpc855 remote stub that implements Z0/z0. > > This worked entirely as expected. Auto-detection > > used to attempt Z0, discover it was unsupported, > > and refrained from ever trying it again. Naively I > > assumed that the remaining Zt variants would behave > > similarly. This is not the case. > > It should be the case. > > > So where do I go to enable ppc hw breaks/watches? > > ``set debug remote 1'' to see exactly what the host/target are doing. Been there. Done that. The culprit is remote.c/remote_check_watch_resources which is hardwired via the earlier definitions: int remote_hw_watchpoint_limit = 0; int remote_hw_breakpoint_limit = 0; For now I have added comparisons between chip names and TARGET_ARCHITECTURE->printable_name along with corresponding known numbers of resource. It ain't pretty but it does work. Am I missing something? I do not see a parameterized abstraction here that would operate off the # of hw breakpoint resources, the # of hw watchpoint resource and an indication that heterogeneous watch sets are supported (see the "ot" argument to remote_check_watch_resources). Nor do I see a way to provide a chip-specific implementation of to_can_use_hw_breakpoint. (But then I have zero grasp of how architectural parameterization works. I just grep and look for obvious patterns that I can mimic.) /john