Re: [v4 2/2] multi-executable support (new v5 patch included)

[Pedro Alves <pedro at codesourcery dot com>]

On Sunday 06 September 2009 04:14:08, Eli Zaretskii wrote:
> > From: Pedro Alves <pedro@codesourcery.com>
> > Date: Sat, 5 Sep 2009 22:15:32 +0100
> > 
> > > IOW, I don't understand why we need to group inferiors by sspaces.
> > 
> > I don't see how to model vfork (in the shared region) (, or DICOS)
> > with just that.  To the extreme, if you load a shared library in
> > a vfork child, the parent ends up with it loaded too.
> 
> Sorry, I don't understand this problem.  Could you elaborate, please?

With the DICOS model, here's what we have currently (and it is
what made more sense when we added multi-process support for this
target, which was the first target that we added multi-process to).

 (gdb) tar extended-remote foo:9999
 ...
 (gdb) info sharedlibrary
 From                To                  Syms Read   Shared Object Library
 0x00007ffff7de0a60  0x00007ffff7df6d44  Yes         so1.so
 0x00007ffff7bb56a0  0x00007ffff7bd1cf8  Yes         so2.so
 0x00007ffff79901b0  0x00007ffff799cf88  Yes         so3.so
 0x00007ffff7710eb0  0x00007ffff774f258  Yes         so4.so
 ...
 (gdb) info inferiors
 No inferiors.

Remember that with extended-remote when you connect, gdb is
not attached to any inferior.  But, in the DICOS case, even when you're not
attached to any process, you already know that layout of the
target memory, and it's list of shared libraries and symbols.  Those
are not an "inferior" property.  That would not be true against a linux
gdbserver, for example.  It would be somewhat strange that
there's already an inferior listed on DICOS.  You want to be
able to do this:

(gdb) attach 123
Attached to process 123.
(gdb) attach 124
Attached to process 124.
(gdb) attach 125
Attached to process 125.

That is, you don't specify which program the inferior
is running, and gdb doesn't warn you that a running program
is already being debugged when you do "attach".  There's no
(useless, at least currently) a pre step of "add-inferior" for
each attach.

However, when debugging against a conventional unix-like target,
even if it support multi-process, you do want GDB to say:

(gdb) start
...
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n)  

Otherwise, it just gets too confusing.  IMO, it's of important that
the single-inferior case works like it always has been, as that's
the use case most users will use and are used to.

The way I had solved this was by decoupling "inferiors" from
"(virtual) address space + its set of loaded symbols".

> > Note that the current GDB model is that inferiors only exist
> > after a "run", that is, inferior ~= process.  Before "run",
> > there's no inferior, "info inferiors" is empty, yet, you
> > have a program loaded already.
> 
> That's the underlying technicality.  

No, I was really talking about the user visible model.  GDB
has worked like that since ever, even before "info inferiors"
was added.  Plus, this way of thinking has now been migrated
to MI and to frontends.  Most importantly, to MI's
"thread group" concept:

 (gdb) -exec-run
 =thread-group-created,id="829"
 =thread-created,id="1",group-id="829"

> From user perspective, we could 
> certainly think that the inferior ``exists'' as soon as there's a
> possibility to issue the `file' command without replacing the
> already existing inferiors.

That somewhat restricts us to the unix model.  I know that other
debuggers do that (I can think of Frysk and TotalView, for
example), but, those can afford thinking the whole world
is unix.

> > We need multiple simultaneous such states.
> 
> Which states?

The state the new symbol-space object collects.  That is,
the "executable + shared libraries + symbols" + all that
can exist without an inferior.


OTOH, if this sounds confusing to you, it's almost certain
it will sound confusing to most users too.  I'm one of those that
needs to try and get a feel for things, so, i've spent a bit
reworking things around to implement that add-inferior model, and
here's what we have now:

>./gdb ./gdb
(top-gdb) info inferiors
  Num  Description       Executable
* 1    <null>            /home/pedro/gdb/sspaces/build/gdb/gdb

(top-gdb) info inferiors
  Num  Description       Executable
* 1    process 1429      /home/pedro/gdb/sspaces/build/gdb/gdb

(top-gdb) kill
Kill the program being debugged? (y or n) y
(top-gdb) info inferiors
  Num  Description       Executable
* 1    <null>            /home/pedro/gdb/sspaces/build/gdb/gdb

(top-gdb) add-inferior
Added inferior 2
1 inferiors added.

(top-gdb) info inferiors
  Num  Description       Executable
  2    <null>
* 1    <null>            /home/pedro/gdb/sspaces/build/gdb/gdb

(top-gdb) inferior 2
[Switching to inferior 2 [process 0] (<noexec>)]

(top-gdb) file /home/pedro/gdb/tests/threads
Reading symbols from /home/pedro/gdb/tests/threads...done.

(top-gdb) info inferiors
  Num  Description       Executable
* 2    <null>            /home/pedro/gdb/tests/threads
  1    <null>            /home/pedro/gdb/sspaces/build/gdb/gdb

(top-gdb) start
Temporary breakpoint 4 at 0x400640: file threads.c, line 35.
Starting program: /home/pedro/gdb/tests/threads
[Thread debugging using libthread_db enabled]

Temporary breakpoint 4, main () at threads.c:35
35          long i = 0;
(top-gdb) info inferiors
  Num  Description       Executable
* 2    process 1526      /home/pedro/gdb/tests/threads
  1    <null>            /home/pedro/gdb/sspaces/build/gdb/gdb


The symbol-spaces concept is still needed and is still there, but
the user doesn't see them anymore.  I've moved "info symbol-spaces"
to "maintenanced info symbol-spaces".

This is similar, yet different from what was in the
multiprocess-20081120-branch.  In that branch, you'd have
proto-inferiors (inferiors with pid == 0, like that <null>
above), but, when you issued a "run", that would still created
yet another inferior.  That turned out to be a bad idea.

So, in this new version, an inferior ID is stable across
a "run" or "attach".  This probably makes things simpler
for python scripting.


I've tweaked things around so that MI's thread-groups are
created at the same time as before, but obviously, MI needs to
be extended to be able to support multi-exec + multi-inferiors
properly.


Now, I've tried to make DICOS fit into this, but since there's always an
inferior, you'll see that useless (and probably confusing) inferior
listed:

 (gdb) tar extended-remote foo:9999
 ...
 (gdb) info sharedlibrary
 From                To                  Syms Read   Shared Object Library
 0x00007ffff7de0a60  0x00007ffff7df6d44  Yes         so1.so
 0x00007ffff7bb56a0  0x00007ffff7bd1cf8  Yes         so2.so
 0x00007ffff79901b0  0x00007ffff799cf88  Yes         so3.so
 0x00007ffff7710eb0  0x00007ffff774f258  Yes         so4.so
 ...
 (gdb) info inferiors
  Num  Description       Executable
* 1    <null>            

 (gdb) attach 123
 Attached to process 123.
 (gdb) info inferiors
  Num  Description       Executable
  1    <null>            
* 2    Process 2323

It's a shame, and that was one of my main concerns (that we'd
end up getting too stuck in the unix model of things) but I guess
we can live with it somehow.


Does this make more sense to you?  What do others think?


I'm CCing Mark and in case he has anything to say from the
frontend/DICOS side of things (and in case he is around currently,
which I know is probably not the case), and Vladimir in
case he has something to say in the MI/frontend side of things.


It would great have this settled before GDB 7.0, so that 7
0 doesn't start off with a half-baked multi-inferior model,
different from 6.8's multi-forks, only to change it again
shortly after the release...  What do people think about
that?

I'm attaching the current patch gzipped.  The changelogs
and the docs need to be updated yet, though.  I'll handle that
next and repost appropriately if people think this is better.


As before, no regressions on x86_64-unknown-linux-gnu native
and gdbserver.

-- 
Pedro Alves

Attachment: multiexec_always_inferior.diff.gz
Description: GNU Zip compressed data