From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27069 invoked by alias); 25 Jun 2009 22:18:49 -0000 Received: (qmail 27061 invoked by uid 22791); 25 Jun 2009 22:18:48 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 25 Jun 2009 22:18:43 +0000 Received: (qmail 26469 invoked from network); 25 Jun 2009 22:18:41 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Jun 2009 22:18:41 -0000 From: Pedro Alves To: Aleksandar Ristovski Subject: Re: [patch] gdbserver: Add support for Z0/Z1 packets Date: Thu, 25 Jun 2009 22:18:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org, Doug Evans References: <200906242011.16184.pedro@codesourcery.com> <4A427DAF.7010007@qnx.com> In-Reply-To: <4A427DAF.7010007@qnx.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200906252319.45428.pedro@codesourcery.com> 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: 2009-06/txt/msg00690.txt.bz2 On Wednesday 24 June 2009 20:25:35, Aleksandar Ristovski wrote: > So, I would make it something like I proposed (if either is > NULL, it's unsupported - also makes a clear statement to new > target implementors). IMO, hardly a real problem. Even if one implements both callbacks one needs to be sure to handle e.g., one of z2 and Z2 on each of them. It just looks unnecessary cautiousness to me. We've not cared for that for a long while in server.c, and don't see much of a point we have to now --- it's not like someone adding support for inserting HW breakpoint wouldn't notice that she missed adding support for removing it. OTOH, it makes the code a bit more tidy to not care about it --- it's just mostly about avoiding a NULL deference as is. I've checked the patch in. If we need to split this up, it's really a trivial change, so let's worry about it then, and move on. As for naming, thinking about the GDB side, GDB is a bit stuck to calling everything "breakpoints" --- breakpoints, watchpoints, catchpoints, and now tracepoints are all subsets of "breakpoints". The HPD spec, Frysk and TotalView (well both of these are HPD influenced) at least, call all these "actionpoints". Personally, I wish we'd call them actionpoints too, and have "info actionpoints" show all of those, "info breakpoints" show only breakpoints, "info watchpoints" show only watchpoints, etc. But I'm sure it is not a practical change at this point ( is it ?? :-) ) -- Pedro Alves