From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9944 invoked by alias); 18 Sep 2007 21:45:33 -0000 Received: (qmail 9934 invoked by uid 22791); 18 Sep 2007 21:45:33 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Sep 2007 21:45:29 +0000 Received: (qmail 27235 invoked from network); 18 Sep 2007 21:45:27 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Sep 2007 21:45:27 -0000 To: Emi SUZUKI Cc: gdb-patches@sourceware.org Subject: Re: [RFC] checking the Z-packet support on gdbserver References: <20070913.210822.19763360.emi-suzuki@tjsys.co.jp> <20070914.183913.226021396.emi-suzuki@tjsys.co.jp> From: Jim Blandy Date: Tue, 18 Sep 2007 21:45:00 -0000 In-Reply-To: <20070914.183913.226021396.emi-suzuki@tjsys.co.jp> (Emi SUZUKI's message of "Fri, 14 Sep 2007 18:39:13 +0900") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00245.txt.bz2 Emi SUZUKI writes: > Well, I understood casually that the answer of 'qSupported' packet > would tell the support for the other 'q' packets from the current > implementaion... According to the description in the info, definitely > it would make sense. How about the attached? Actually, thinking more carefully: what effect will this change have on existing stubs that do support hardware watchpoints, but don't include 'Z0+', etc. in their qSupported responses? Won't it mean that new GDBs will decline to use hardware watchpoints with them? It seems to me that, when GDB has no information about 'Zx' availability, it should continue to assume that they are available and then get errors if not, as it does now, but it should also work with smarter stubs, like your patched GDB server, to provide a better user experience. 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.