From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-48830-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 9110 invoked by alias); 10 May 2007 03:18:34 -0000
Received: (qmail 9093 invoked by uid 22791); 10 May 2007 03:18:33 -0000
X-Spam-Check-By: sourceware.org
Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (213.8.233.22)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 May 2007 03:18:30 +0000
Received: from HOME-C4E4A596F7 (IGLD-80-230-160-16.inter.net.il [80.230.160.16]) 	by nitzan.inter.net.il (MOS 3.7.3a-GA) 	with ESMTP id GSD27863 (AUTH halo1); 	Thu, 10 May 2007 06:18:28 +0300 (IDT)
Date: Thu, 10 May 2007 03:18:00 -0000
Message-Id: <ubqgt1i4a.fsf@gnu.org>
From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Jacobowitz <drow@false.org>
CC: gdb-patches@sourceware.org, gdb@sourceware.org
In-reply-to: <20070509201627.GA23422@caradoc.them.org> (message from Daniel 	Jacobowitz on Wed, 9 May 2007 16:16:27 -0400)
Subject: Re: [rfc / remote protocol] Remote shared library events
Reply-to: Eli Zaretskii <eliz@gnu.org>
References:  <20070509201627.GA23422@caradoc.them.org>
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2007-05/txt/msg00153.txt.bz2

> Date: Wed, 9 May 2007 16:16:27 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sourceware.org
> 
> Eli, do the manual changes look OK?

Yes, but see a few comments below.

> +* The GDB remote protocol "T" stop reply packet now supports "dll",
> +"load", and "unload" pairs.  Combined with the qfDllInfo and qsDllInfo

qfDllInfo and qsDllInfo are new, so please say that (as you do below
for T).

> +@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.

I think we need to explain what is ``hexname'' here, unless it is
already used and explained in the preceding portion of this section.

Also, should we have some index entries here?

> +until the target responds with @samp{l} (lower-case el, for
                                                       ^^
I believe the letter's name is ``ell''.

> +Reply:
> +@table @samp
> +@item m Name=@var{hexname},TextSeg=@var{textaddr}@r{[},DataSeg=@var{dataaddr}@r{]}

Does this long line look good in print?

> +@item m @var{library}; @var{library}@dots{} @r{[}; l@r{[}

Did you really mean two left [ brackets here?