From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30681 invoked by alias); 18 Sep 2007 21:17:20 -0000 Received: (qmail 30673 invoked by uid 22791); 18 Sep 2007 21:17:20 -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:17:13 +0000 Received: (qmail 23600 invoked from network); 18 Sep 2007 21:17:11 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Sep 2007 21:17:11 -0000 To: Emi SUZUKI Cc: gdb-patches@sourceware.org, Daniel Jacobowitz 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:17: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/msg00243.txt.bz2 Emi SUZUKI writes: > From: Jim Blandy > Subject: Re: [RFC] checking the Z-packet support on gdbserver > Date: Thu, 13 Sep 2007 10:05:50 -0700 > >> Emi SUZUKI writes: >> > Would anyone give me any comments how it should be treated as a whole? >> > Defines another packet for it? Applies as proposed and notes "it >> > might not work with older versions of gdbserver" ? >> >> I wonder, would it make sense to have GDB assume that hardware >> watchpoints are *not* available on remote targets, and then have >> gdbserver send a 'qSupported' packet stubfeature that tells GDB that >> hardware watchpoints are okay? > > 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? This looks good to me. Dan should probably approve the gdbserver side, but that looks appropriately done to me, too. In remote.c, I noticed two things: - You want 'resource', not 'resouce'. - It seems to me that hardware_resource_to_Z_packet should just return one of the PACKET_Z[0-4], ... constants directly, instead of returning a Z_PACKET_* constant and letting remote_check_Zpacket_support convert that to a PACKET_Z? enum value.