Re: [patch] Forbid run with a core file loaded

[Pedro Alves <pedro at codesourcery dot com>]

On Tuesday 08 June 2010 03:32:29, Tom Tromey wrote:
> Jan> I hope you agree the target stack should be made specific for each
> Jan> inferior.
> 
> Pedro> I've gone back and forth on that for a while with the multi-exec
> Pedro> work.  It's trickier than that.
> 
> How else would you propose letting people attach to multiple inferiors
> using multiple targets?  This seems like a reasonable thing to want to
> do, e.g., debugging a distributed application of some kind.

It is.  It's the obvious next step.  It's the missing step into being
able to debug parallel MPI programs running on different machines.  But
that also obviously needs to consider user interface issues -- more than
just an internal implementation detail.

> Pedro> Consider the extended-remote target --- if you do "add-inferior;
> Pedro> <inf 2 created>; inferior 2; run", if we simply had a target
> Pedro> stack per inferior, then when you get to "run", you'd only have
> Pedro> "exec" on the inferior 2's stack, but you wanted extended-remote
> Pedro> to handle creating the inferior.
> 
> I don't really know enough about the target API, but this seems fixable.
> "Target stack per inferior" does not necessarily imply that the targets
> cannot be shared, just that conceptually each inferior carries its own.

Of course everything is fixable.  tricker != impossible != undesirable.
If you go the simply route of simply sharing the target stack between
all inferiors that share the same process_stratum target, you have what
we have today.  None of that would make Jan's patch any different, because it
would still need to be careful to not pop random targets off the stack
when _one_ inferior is gone.  If you say that you'd only share the _targets_ and
not the _stack_ between inferiors, then you'd have to rethink things like
the target->beneath pointer, as that is embedded within the target_ops object.

-- 
Pedro Alves