This is the mail archive of the
mailing list for the GDB project.
Re: [v4 2/2] multi-executable support
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
> 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.)