From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6281 invoked by alias); 17 Feb 2009 21:45:18 -0000 Received: (qmail 6273 invoked by uid 22791); 17 Feb 2009 21:45:16 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BARRACUDA_BRBL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Feb 2009 21:45:10 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1LZXkU-00084p-S4 for gdb-patches@sources.redhat.com; Tue, 17 Feb 2009 21:45:03 +0000 Received: from h86-62-88-129.ln.rinet.ru ([86.62.88.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Feb 2009 21:45:02 +0000 Received: from vladimir by h86-62-88-129.ln.rinet.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Feb 2009 21:45:02 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: MI solib notification Date: Tue, 17 Feb 2009 21:59:00 -0000 Message-ID: References: <200901310010.46738.vladimir@codesourcery.com> <200902172208.37427.vladimir@codesourcery.com> <200902172244.48437.vladimir@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 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-02/txt/msg00369.txt.bz2 Vladimir Prus wrote: > Eli Zaretskii wrote: > >>> From: Vladimir Prus >>> Date: Tue, 17 Feb 2009 22:44:48 +0300 >>> Cc: drow@false.org, >>> gdb-patches@sources.redhat.com, >>> nickrob@snap.net.nz >>> >>> How about the attached, instead? >>> [...] >>> +@item =library-loaded,... >>> +Reports that a new library file was loaded by the program. This >>> +notification has 4 fields---@var{id}, @var{target-name}, >>> +@var{host-name}, and @var{symbols-loaded}. The @var{id} field is an >>> +opaque identifier of the library. For remote debugging case, >>> +@var{target-name} and @var{host-name} fields give the name of the >>> +library file on the target, and on the host respectively. For native >>> +debugging, both those fields have the same value. The >>> +@var{symbols-loaded} field reports if the debug symbols for this >>> +library are loaded. >> >> That's okay, but now I ask again why not do it like I suggested in the >> first place, viz.: >> >> @item =library-loaded,@var{info} >> Reports that a new library file was loaded by the program. @var{info} >> includes 4 fields: >> >> @table @code >> @item id="@var{id}" >> Opaque identifier of the library. >> @item target-name="@var{target-name}" >> @itemx host-name="@var{host-name}" >> For remote debugging case, @var{target-name} and @var{host-name} >> fields give the name of the library file on the target, and on the >> host respectively. For native debugging, both those fields have the >> same value. >> ... >> >> etc., you get the idea. What you suggested now is very close to this, >> but I think my suggestion makes it easier to read and grasp. > > I think the way you suggest is more complex. It introduces a new symbol 'info' > that does not actually correspond to standalone entity in MI output and users > might begin to wonder what info actually is, and how it includes fields. Saying > that notification itself has 4 fields is more direct. Also, table is relatively more heavyweight mechanism to describe just 4 fields, using 4 sentences total. - Volodya