Re: [RFA 01/08] multi-process support: struct inferior

[Pedro Alves <pedro@codesourcery.com>]

On Friday 12 September 2008 17:08:16, Eli Zaretskii wrote:
> > From: Pedro Alves <pedro@codesourcery.com>
> > 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