From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6034 invoked by alias); 18 May 2007 16:04:58 -0000 Received: (qmail 5999 invoked by uid 22791); 18 May 2007 16:04:56 -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; Fri, 18 May 2007 16:04:53 +0000 Received: (qmail 934 invoked from network); 18 May 2007 16:04:50 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 May 2007 16:04:50 -0000 To: gdb-patches@sourceware.org Cc: gdb@sourceware.org Subject: Re: [rfc / remote protocol] Remote shared library events References: <20070509201627.GA23422@caradoc.them.org> <20070518002701.GA13859@caradoc.them.org> From: Jim Blandy Date: Fri, 18 May 2007 16:04:00 -0000 In-Reply-To: <20070518002701.GA13859@caradoc.them.org> (Daniel Jacobowitz's message of "Thu, 17 May 2007 20:27:01 -0400") 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-05/txt/msg00309.txt.bz2 Daniel Jacobowitz writes: > 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. Sorry --- of course the @var{r} associated with the dllstop isn't meaningless. Regarding the other pairs, I didn't realize that one wanted expedited registers for DLL events; would we actually use them?