From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4036 invoked by alias); 16 May 2007 22:59:00 -0000 Received: (qmail 4018 invoked by uid 22791); 16 May 2007 22:58:58 -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; Wed, 16 May 2007 22:58:55 +0000 Received: (qmail 29535 invoked from network); 16 May 2007 22:58:53 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 May 2007 22:58:53 -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> From: Jim Blandy Date: Wed, 16 May 2007 22:59:00 -0000 In-Reply-To: <20070509201627.GA23422@caradoc.them.org> (Daniel Jacobowitz's message of "Wed, 9 May 2007 16:16:27 -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-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-05/txt/msg00063.txt.bz2 Daniel Jacobowitz writes: > All comments welcome! > > +@item > +If @var{n} is @samp{load}, then the packet indicates a DLL load event, > +and @var{r} describes the newly loaded library. The library format is > +the same used in @samp{qfDllInfo} replies (@pxref{qfDllInfo}), e.g.@: > +@samp{load:Name=@var{hexname},TextSeg=@var{textaddr}}. The entry may > +end in @samp{,nop} if this library was already mapped, e.g.@: by an > +earlier call to @code{LoadLibrary}. @var{aa} should be @samp{05}, the > +trap signal. > + > +@item > +If @var{n} is @samp{unload}, then the packet indicates a DLL unload > +event, and @var{r} describes the unloaded library. @var{r} is a list > +of comma-separated @samp{Key=Value} pairs, similar to a > +@samp{qfDllInfo} reply. The name, the segment offsets, or both may be > +used to specify which DLL to unload, e.g.@: > +@samp{unload:Name=@var{hexname}} or > +@samp{unload:Name=@var{hexname},TextSeg=@var{textaddr}}. The entry > +may end in @samp{,nop} if this library is still mapped, e.g.@: by > +another open handle. @var{aa} should be @samp{05}, the trap signal. > + > +@item > +If @var{n} is @samp{dll}, then the packet indicates that the loaded > +DLLs have changed. @value{GDBN} should use @samp{qfDllInfo} to fetch > +a new list of loaded libraries. @var{r} is ignored. @var{aa} should > +be @samp{05}, the trap signal. 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. > +Reply: > +@table @samp > +@item m Name=@var{hexname},TextSeg=@var{textaddr}@r{[},DataSeg=@var{dataaddr}@r{]} > +A single loaded library. @var{hexname} is the name of the library, > +as a hexadecimal sequence of ASCII characters. @var{textaddr} is the > +load address for the text segment of the library. @var{dataaddr} is > +the load address for the data segment of the library, if necessary. > +If only @var{textaddr} is provided, the data segment will be relocated > +by the same amount as the text segment. > + > +Other @samp{Key=Value} pairs may be added later to describe target > +specific data. 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. > +If the packet ends with @samp{;l} then no further @samp{qsDllInfo} > +packet will be sent. Perfect. Same trick as with qXfer.