From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9842 invoked by alias); 27 Oct 2011 07:04:28 -0000 Received: (qmail 9790 invoked by uid 22791); 27 Oct 2011 07:04:26 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 27 Oct 2011 07:04:09 +0000 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RJK0U-0003hX-AT; Thu, 27 Oct 2011 03:04:06 -0400 Date: Thu, 27 Oct 2011 07:30:00 -0000 Message-Id: From: Eli Zaretskii To: Sergio Durigan Junior CC: gdb-patches@sourceware.org In-reply-to: (message from Sergio Durigan Junior on Wed, 26 Oct 2011 19:07:45 -0200) Subject: Re: [PATCH] Implement new `info core mappings' command Reply-to: Eli Zaretskii References: 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: 2011-10/txt/msg00716.txt.bz2 > From: Sergio Durigan Junior > Date: Wed, 26 Oct 2011 19:07:45 -0200 > > *** Changes since GDB 7.3.1 > > +* GDB has a new `info core mappings' command. It displays the memory > + regions in a corefile, similar to `info proc mappings' command. This is okay. > + while (argv != NULL && *argv != NULL) > + { > + if (strncmp (argv[0], "mappings", strlen (argv[0])) == 0) > + { > + mappings_f = 1; > + } > + else if (strncmp (argv[0], "all", strlen (argv[0])) == 0) > + { > + all = 1; > + } > + argv++; > + } What is this "all" stuff about? > +@cindex core dump file This index entry is too general, it sounds like this section describes everything about core dump files that GDB supports. Better qualify it, e.g. @cindex core dump file, list mapped memory > +@cindex memory address space mappings Likewise; you need to qualify this so it's clear it only talks about memory mappings in the context of core file debugging. > +@item info core > +@item info core mappings You cannot have 2 @item's in a row. All but the first one need to be @itemx. > +Report the memory address space ranges accessible in the core file. I would lose the "space" part. I think a short example of output would be good here. > One thing I am not sure is where to put the entry for this command on > the documentation. I decided to put it below `info proc', but I'd be > glad if you could give your opinions. I don't think it's good to put it in the same section as "info proc", because we say at the beginning of the section Many versions of SVR4 and compatible systems provide a facility called @samp{/proc} that can be used to examine the image of a running process using file-system subroutines. But this new command has nothing to do with /proc, and does not need /proc support to work, right? If /proc is indeed irrelevant, then I'd prefer a separate @subsection alongside this one. You'd need to add some short explanation of the background and use case(s) for this command, but having that is a good idea anyway: as written now, this command lands on the reader out of the blue, more or less. Thanks.