From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9166 invoked by alias); 20 Sep 2007 09:49:44 -0000 Received: (qmail 9147 invoked by uid 22791); 20 Sep 2007 09:49:43 -0000 X-Spam-Check-By: sourceware.org Received: from imx12.toshiba.co.jp (HELO imx12.toshiba.co.jp) (61.202.160.132) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Sep 2007 09:49:33 +0000 Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id l8K9nPbo000103; Thu, 20 Sep 2007 18:49:25 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id l8K9nOLT005148; Thu, 20 Sep 2007 18:49:24 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id UAA05146; Thu, 20 Sep 2007 18:49:24 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id l8K9nObZ012110; Thu, 20 Sep 2007 18:49:24 +0900 (JST) Received: from mx.tjsys.co.jp by toshiba.co.jp id l8K9nM72012742; Thu, 20 Sep 2007 18:49:23 +0900 (JST) Received: from voltage-out.tjsys.co.jp (voltage-out.tjsys.co.jp [157.79.3.51]) by mx.tjsys.co.jp (8.12.11/8.12.11) with ESMTP id l8K9nMkq002971; Thu, 20 Sep 2007 18:49:22 +0900 (JST) Received: from is-com10 ([157.79.3.71]) by voltage-out.tjsys.co.jp (8.13.1/8.13.1) with SMTP id l8K9nHMS022342; Thu, 20 Sep 2007 18:49:17 +0900 Received: from localhost (liscom0720.bspj.cosdc.toshiba.co.jp [133.114.93.18]) by ims.tjsys.co.jp (iPlanet Messaging Server 5.2 HotFix 2.10 (built Dec 26 2005)) with ESMTP id <0JON005TLVA14Z@ims.tjsys.co.jp>; Thu, 20 Sep 2007 18:49:15 +0900 (JST) Date: Thu, 20 Sep 2007 09:49:00 -0000 From: Emi SUZUKI Subject: Re: [RFC] checking the Z-packet support on gdbserver In-reply-to: To: jimb@codesourcery.com, gdb-patches@sourceware.org Message-id: <20070920.184918.158391937.emi-suzuki@tjsys.co.jp> MIME-version: 1.0 X-Mailer: Mew version 5.2.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Content-type: Text/Plain; charset=us-ascii Content-transfer-encoding: 7bit References: <20070914.183913.226021396.emi-suzuki@tjsys.co.jp> X-WAuditID: 0709201849150000015587 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00269.txt.bz2 Hello Jim, Thank you for your review and sorry for a bit later response. From: Jim Blandy Subject: Re: [RFC] checking the Z-packet support on gdbserver Date: Tue, 18 Sep 2007 14:45:27 -0700 > So, would it make more sense for the initial state of the Z packets in > remote_protocol_features to be PACKET_SUPPORT_UNKNOWN, and for > gdbserver to transmit either Zx- or Zx+ as appropriate? Thus, in your > case, as soon as GDB connected to the target it would know that > hardware watchpoints weren't available, but on connection to some > older stub which said nothing about the Z packets in its qSupported > response (if it gave such a response at all), GDB would continue to > try hardware watchpoints. Hmmm. But my primal worry for the current behavior is that working with the stubs which do not support hardware watchpoints (including the older ones) cause errors. Although I know it would be a passive attitude towards using hardware watchpoints, using software ones instead of hardware ones should not cause errors. And if the older stubs have Z-packet supports, you can activate them by setting "set remote Z-packet on" or something, no matter how the initial state of Z-packets in remote_protocol_features are. Actually, I couldn't find any reason why the initial value of remote_hw_watchpoint_limit defined in remote.c is -1, and it stands for that hardware watchpoints are available... My best regards, -- Emi SUZUKI / emi-suzuki at tjsys.co.jp