Re: [v4 2/2] multi-executable support

[Pedro Alves <pedro at codesourcery dot com>]

On Saturday 05 September 2009 21:14:16, Eli Zaretskii wrote:

> Here's my question: Why do we need a container for inferiors (that you
> call sspace)?  I understand why we need a way of starting another
> inferior _in_addition_to_ the existing ones (as opposed to
> _instead_of_ the existing one).  But wouldn't it be enough to have one
> command -- "add-inferior", say -- to provide the same set of features
> you want, i.e. the ability to debug several inferiors at the same
> time?
> 
> 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.

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.  We need multiple
simultaneous such states.  You can actually ignore
"info inferiors" if you like.  "info programs"/"info sspaces"
is basically what you suggest above.

(Note that 'add-symbol-space -exec EXEC' and 'close-symbol-space'
are just there for convenience.  We can live with just
'add-symbol-space'/'add-program', or whatever the spelling is.)

-- 
Pedro Alves