From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6116 invoked by alias); 18 May 2007 00:27:16 -0000 Received: (qmail 6099 invoked by uid 22791); 18 May 2007 00:27:13 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 May 2007 00:27:06 +0000 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id 1FC544B267; Thu, 17 May 2007 19:27:02 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id E68C94B262; Thu, 17 May 2007 19:27:01 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1HoqJB-0003bp-8u; Thu, 17 May 2007 20:27:01 -0400 Date: Fri, 18 May 2007 00:27:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sourceware.org, gdb@sourceware.org Subject: Re: [rfc / remote protocol] Remote shared library events Message-ID: <20070518002701.GA13859@caradoc.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sourceware.org, gdb@sourceware.org References: <20070509201627.GA23422@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-09) 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-05/txt/msg00303.txt.bz2 On Wed, May 16, 2007 at 03:58:52PM -0700, Jim Blandy wrote: > It seems odd to me that it's an @var{n} that distinguishes the reason > for the stop; the @var{AA}, the @var{r}, and any other @var{r}:@var{n} > pairs are essentially meaningless. I'd rather see an entirely new > stop reply packet type --- 'L', say --- with subsequent name/value > pairs, like those in a q[fs]DllInfo packet's 'm' response. I don't know why you say they're meaningless. @var{AA} is unused, but @var{r} describes the exact reason for the stop (which library was loaded or unloaded), and other @var{r}:@var{n} pairs are treated exactly as they are for T packets - they supply useful registers. I'd have to add the expedited register support to any new reply packet too, which would make it basically T without the signal number; this version seems to complicate the protocol less. > Should the protocol allow Key=Value pairs to appear in any order? I > don't think you really need to revise the reply template to show this, > just a note to that effect would be plenty. Yes indeed. -- Daniel Jacobowitz CodeSourcery