From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27038 invoked by alias); 12 Sep 2008 20:00:29 -0000 Received: (qmail 27028 invoked by uid 22791); 12 Sep 2008 20:00:28 -0000 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.31) with ESMTP; Fri, 12 Sep 2008 19:59:40 +0000 Received: from HOME-C4E4A596F7 ([87.70.226.149]) by i_mtaout3.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K73004VSM8RPIS1@i_mtaout3.012.net.il> for gdb-patches@sourceware.org; Fri, 12 Sep 2008 23:00:27 +0300 (IDT) Date: Fri, 12 Sep 2008 20:00:00 -0000 From: Eli Zaretskii Subject: Re: [RFA 01/08] multi-process support: struct inferior In-reply-to: <200809121820.43518.pedro@codesourcery.com> X-012-Sender: halo1@inter.net.il To: Pedro Alves Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: References: <200809121637.34647.pedro@codesourcery.com> <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/msg00281.txt.bz2 > From: Pedro Alves > Date: Fri, 12 Sep 2008 18:20:43 +0100 > > > > +@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. Ah, but no one said anything about attaching to multiple inferiors yet. This text is written as if debugging multiple inferiors was discussed in the manual everywhere since page 1, but it wasn't. > This will grow in documentation and usefulness as later patches, > documentation and multi-exec support is submitted. Right, but we still need some introductory text to break the news on the reader that GDB can debug several inferiors at once. A couple of use cases where this would be useful will not do any harm, either. IOW, people who debug programs usually do that one program at a time, so we cannot seamlessly start talking about commands that support multi-process paradigm without introducing the reader to the feature. > (gdb) r > Starting program: /home/pedro/gdb/tests/threads32 > [New inferior 16983] > ^^^^^^^^^^^^^^^^^^^^ Should we perhaps automatically set print inferior-events on when a second inferior is started?