From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 406 invoked by alias); 12 Sep 2008 17:21:39 -0000 Received: (qmail 396 invoked by uid 22791); 12 Sep 2008 17:21:38 -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; Fri, 12 Sep 2008 17:20:46 +0000 Received: (qmail 847 invoked from network); 12 Sep 2008 17:20:43 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Sep 2008 17:20:43 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [RFA 01/08] multi-process support: struct inferior Date: Fri, 12 Sep 2008 17:21:00 -0000 User-Agent: KMail/1.9.9 References: <200809121637.34647.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809121820.43518.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: 2008-09/txt/msg00277.txt.bz2 On Friday 12 September 2008 17:08:16, Eli Zaretskii wrote: > > From: Pedro Alves > > Date: Fri, 12 Sep 2008 16:37:34 +0100 > > > > +@node Inferiors > > +@section Listing Inferiors > > Some index entry should be here. > > Also, I'm not sure this should be a top-level @section (but if it is, > I believe you will have to add it to the top-level menu as well). How > about making it a subsection of "Running"? Fine with me. I was just putting it close to the current docs for multi-fork/multi-process support. In fact, I'm just trying to place the documentation of the new commands somewhere. I'm quite sure that Stan will end up expanding/rewriting this much with the docs for: http://sourceware.org/ml/gdb/2008-08/msg00169.html > > +@value{GDBN} keeps track of the inferiors under control, be them > > +either running processes, core files, or remote targets without a > > +notion of processes, but which nonetheless have execution, and allows > > +the user to query and be notified about them uniformally, using the > > +commands below. > > This text falls short of explaining why these features are useful. > Can we add something to explain this better? Hmmm, when you're attached to multiple inferiors, you naturally want to be able to get a list of those. I didn't put an example up, as currently it is boring: (gdb) info inferiors * 2 16837 1 16836 This will grow in documentation and usefulness as later patches, documentation and multi-exec support is submitted. In the mean time, it'd be helpful to know what sort of something you'd like explained better, as obviously, I thought that the description under the commands was enough. But that's surelly because I've been staring at these issues for too long. :-) > > +The @code{set print inferior-events} command allows you to enable or > > +disable printing of messages when @value{GDBN} notices that new > > +inferiors have started or that inferiors have exited or have been > > +detached. By default, these messages will not be printed. > > If the default is off, then perhaps we should tell when would the user > want them on. But maybe if you add explanation I asked for above, > they will clarify this as well. Hmmm, since the description of the command explain what it does, I figure the user will want it, when he wants what is described above. This is about the same level of detail as "set print thread-events". I disabled it by default, because it's what GDB does currently. The below is against a multi-process gdbserver: (gdb) b main Breakpoint 1 at 0x80484d5: file threads.c, line 35. (gdb) tar extended-remote :9999 Remote debugging using :9999 (gdb) r Starting program: /home/pedro/gdb/tests/threads32 [New inferior 16983] ^^^^^^^^^^^^^^^^^^^^ Breakpoint 1, main () at threads.c:35 35 long i = 0; (gdb) As we extend the multi-process support, this messages will get a bit smarter (the target may decide to use some other text for the message, like we do with thread messages), but we're not there yet. -- Pedro Alves