> My points here were that for at least some debuggers, a
> naming scheme is all they need, and we should be able to accommodate
Yes, it seems that some advanced "renaming scheme" will fit most of needs.
(I mean if it allows to customize not only debugger name & path, but also
cmd-line options and smth alike)
> Are you calling us a low-quality implementation? ;-)
No, I mean that there is always a way to improve tool, and this way can't
be completed - makin one step will show the next one :)
> Understood. However, our startup philosophy is quite different than
> MPICH's; having a compiled executable as the starter has many more
> benefits than problems (IMHO). You have concretely identified a problem
> -- that there is no flexibility in different debugger bootstrap
> mechanisms -- and a) I agree, b) I think we can fix it easily,
> and c) I would prefer not to revert to scripts as the only solution.
Surely, scripts will lose all orte benefits, such as using MCA and GPR.
> We don't currently support sending arbitrary signals (it certainly can
> be done -- at least in some environments -- we just haven't had a need
> for that yet)
It turned out that gdb doesn't interrupt the inferior execution by getting
SIGINT not from control TTY, so we skip the signal issues at this time.
> IMHO, it would be nice if ORTE could handle "launch
> this job alongside that other job" bookkeeping for you, so that you
> don't need to specify all the location/process placement stuff.
Yes, that is exactly what I mean.
> > It is planned to support only MPI 1.2 for the first release.
> Let us know when you're interested; there's a lot of unanswered
> questions in that arena.
There are enough problems even with MPI 1.2 programs, lets challenge them
> Essentially, yes. We also need to set an MCA param that gets propagated
> out to all the MPI processes telling them to block in MPI_INIT until the
> debugger attaches and changes a value (see
> ompi/debuggers/ompi_totalview.c -- it's called at the very end of
> MPI_INIT, in ompi/runtime/ompi_mpi_init.c).
Surely, I forgot the debugging mode switches.
> Our general rule of implementation in Open MPI is "if we ever want to
> implement something multiple different ways, make it a framework and
> write components).
That is a good way, and the only one to make an extensible software.
Supposed you don't forget the complete documentation for all interfaces :)