From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11437 invoked by alias); 13 Aug 2002 01:11:30 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11430 invoked from network); 13 Aug 2002 01:11:28 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 13 Aug 2002 01:11:28 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g7D0vrl29964 for ; Mon, 12 Aug 2002 20:57:53 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g7D1BQu04858 for ; Mon, 12 Aug 2002 21:11:26 -0400 Received: from romulus.sfbay.redhat.com (IDENT:HKEvbT3w9JQs/7wVDnQXLzCTxOkuWJGH@romulus.sfbay.redhat.com [172.16.27.251]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g7D1BPe26981; Mon, 12 Aug 2002 18:11:25 -0700 Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g7D1BJf02268; Mon, 12 Aug 2002 18:11:19 -0700 Date: Mon, 12 Aug 2002 18:11:00 -0000 From: Kevin Buettner Message-Id: <1020813011119.ZM2267@localhost.localdomain> In-Reply-To: Michael Snyder "Re: [RFA] procfs.c: TARGET_CAN_USE_HARDWARE_WATCHPOINT via target vector" (Aug 12, 5:21pm) References: <1020812213802.ZM1237@localhost.localdomain> <3D585101.CA20A2E2@redhat.com> To: Michael Snyder Subject: Re: [RFA] procfs.c: TARGET_CAN_USE_HARDWARE_WATCHPOINT via target vector Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-08/txt/msg00281.txt.bz2 On Aug 12, 5:21pm, Michael Snyder wrote: > Kevin Buettner wrote: > > > > On Irix, it's possible to debug processes using the o32, n32, and n64 > > ABIs from a single gdb. Unfortunately, due to some limitations with > > the watchpoint support in procfs.c, it is not possible to use hardware > > watchpoints in all cases. (See patch comments for details.) > > > > My first cut at a patch simply changed the macro in > > config/mips/nm-irix5.h. However, since this same solution will be > > required for each platform requiring procfs.c, I decided to use the > > newly added hardware breakpoint facilities in the target vector. > > > > Okay to commit? > > Sure -- but don't you think it should default to zero? > Or is being able to do it the norm? (I don't remember). Here's the part of the patch to look at: > > +/* Return non-zero if we can set a hardware watchpoint of type TYPE. TYPE > > + is one of bp_hardware_watchpoint, bp_read_watchpoint, bp_write_watchpoint, > > + or bp_hardware_watchpoint. CNT is the number of watchpoints used so > > + far. > > + > > + Note: procfs_can_use_hw_breakpoint() is not yet used by all > > + procfs.c targets due to the fact that some of them still define > > + TARGET_CAN_USE_HARDWARE_WATCHPOINT. */ > > + > > +static int > > +procfs_can_use_hw_breakpoint (int type, int cnt, int othertype) > > +{ > > +#ifndef TARGET_HAS_HARDWARE_WATCHPOINTS > > + return 0; > > +#else > > + /* Due to the way that proc_set_watchpoint() is implemented, host > > + and target pointers must be of the same size. If they are not, > > + we can't use hardware watchpoints. This limitation is due to the > > + fact that proc_set_watchpoint() calls address_to_host_pointer(); > > + a close inspection of address_to_host_pointer will reveal that > > + an internal error will be generated when the host and target > > + pointer sizes are different. */ > > + if (sizeof (void *) != TYPE_LENGTH (builtin_type_void_data_ptr)) > > + return 0; > > + > > + /* Other tests here??? */ > > + > > + return 1; > > +#endif > > } So... It returns zero for targets without hardware watchpoint support. It returns 1 for targets with hardware watchpoint support,... UNLESS the host and target pointer sizes don't match, in which case it returns 0. I think the above is what procfs.c targets do for TARGET_CAN_USE_HARDWARE_WATCHPOINT with the exception of the "UNLESS" clause which is new. BTW, it seems to me that we should have some other tests (for type, size, number of existing hardware watchpoints, etc) in the "Other tests here???" section, but I don't really know what these tests should be yet. Also, none of the other procfs.c targets currently seem to care about this, so the functionality will be the same as what we currently have (right or wrong). Thanks for the quick reply. Kevin