From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6086 invoked by alias); 5 Oct 2009 21:57:21 -0000 Received: (qmail 6075 invoked by uid 22791); 5 Oct 2009 21:57:20 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout3.012.net.il (HELO mtaout3.012.net.il) (84.95.2.7) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Oct 2009 21:57:14 +0000 Received: from conversion-daemon.i_mtaout3.012.net.il by i_mtaout3.012.net.il (HyperSendmail v2004.12) id <0KR200000A97JR00@i_mtaout3.012.net.il> for gdb-patches@sourceware.org; Mon, 05 Oct 2009 23:57:10 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.224.43]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KR200AZAABAGOE0@i_mtaout3.012.net.il>; Mon, 05 Oct 2009 23:57:10 +0200 (IST) Date: Mon, 05 Oct 2009 21:57:00 -0000 From: Eli Zaretskii Subject: Re: [v6] multi-executable support In-reply-to: <200910051659.20885.pedro@codesourcery.com> To: Pedro Alves Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83d451o69u.fsf@gnu.org> References: <200910051659.20885.pedro@codesourcery.com> 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-10/txt/msg00112.txt.bz2 > From: Pedro Alves > Date: Mon, 5 Oct 2009 16:59:20 +0100 > > Eli, could you please take a new look at the docs bits? > I may have missed something, but I hope nothing big. Ack. I also spotted a few typos in the comments, see below. > +/* These functions concerns about actual breakpoints inserted in the "These functions concerns" doesn't sound right. > +/* Returns true if {ASPACE1,ADDR1} and {ASPACE2,ADDR2} represent the > + same breakpoint location. In most targets, this is will be true if ^^ I think "is" is redundant here. > + /* The program had previously vforked, and now the child is done > + with the shared memory region, because it exec'ed or exited. > + Note that the event if reported to the vfork parent. This is ^^ Did you mean "is"? > + /* If this is a vfork child exiting, then the pspace and > + aspaces where shared with the parent. Since we're ^^^^^ "were", right? > Index: src/gdb/doc/gdb.texinfo This is okay, but I have a few comments: > +In addition, below each inferior line, @value{GDBN} prints extra > +information that isn't suitable to display in tabular form. For > +example, extra vfork parent/child relationships. How about showing some of that in the example? Otherwise, this note sounds too mysterious, IMO. > +Many commands will work the same with multiple programs as with a > +single program: E.g., @code{print myglobal} will simply display the ^^^^ "e.g.", in lower case. > +Ocasionaly, when debugging @value{GDBN} itself, it may be useful to ^^^^^^^^^^ "Occasionally" > +get more info about the relationship or inferiors, programs, address ^^ "of", I presume > +@smallexample > +(@value{GDBP}) maint info program-spaces > + Id Executable > + 2 goodbye > + Bound inferiors: ID 1 (process 21561) > +* 1 hello > +@end smallexample > +@end table > + > +Here we can see that no inferior is running the program @code{hello}, > +while @code{process 21561} is running the program @code{goodbye}. On > +some targets, it is possible that multiple inferiors are bound to the > +same program space. The most common example is that of debugging both > +the parent and child processes of a @code{vfork} > +call. @xref{Forks,,Debugging Forks}. Since this is about program spaces, not about inferiors, I'd suggest to show an example that includes multiple inferiors in the same program space. Otherwise, this looks awfully similar to "info inferiors" and the purpose of this command remains unclear. > +@code{follow-exec-mode} can be: > + > + > + new - the debugger creates a new inferior and rebinds the process \n\ > +to this new inferior. The program the process was running before\n\ > +the exec call can be restarted afterwards by restarting the original\n\ > +inferior.\n\ > +\n\ > + same - the debugger keeps the process bound to the same inferior.\n\ > +The new executable image replaces the previous executable loaded in\n\ > +the inferior. Restarting the inferior after the exec call restarts\n\ > +the executable the process was running after the exec call.\n\ > +\n\ > +By default, the debugger will use the same inferior."), This looks like copy/paste from the doc strings in the source. It should be removed, I think. > +@value{GDBN} creates a new inferior and rebinds the process to this > +new inferior. The program the process was running before the exec ^^^^ "exec" should be in @code. > +inferior. Restarting the inferior after the exec call restarts the > +executable the process was running after the exec call. This is the > +default mode. Same here. > +(@value{GDBP}) info sspaces Should be "maint info program-spaces", right? > Index: src/gdb/NEWS This is okay, with a couple of comments: > +maint info program-spaces > + List the program spaces loaded into GDB. This should probably be after the *-inferior commands, not before them. > + When the program execs, request to keep the previous executable' ^^^^^^^^^^^ "executable's", right? > + symbol loaded, and load the new executable in a new symbol-space; or > + request GDB to reuse the symbol-space and replace the previous > + executable's symbols with the new executable. I think you want to replace "symbol space" with "program space". > +/* Add a new empty program space to the program space list, and binds it > + to ASPACE. Returns the pointer to the new object. */ Either "add", "bind", and "return", or "adds", "binds", and "returns". > +/* If ARGS is NULL or empty, print information about all symbol > + spaces. Otherwise, ARGS is a text representation of a LONG "program spaces". > +/* All known objfiles are kept in a linked list. This points to the > + root of this list. */ I believe "root" is used for trees. Lists have a "head".