Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

From: Konstantin Karganov (kostik_at_[hidden])
Date: 2005-10-21 09:39:12

> My points here were that for at least some debuggers, a
> naming scheme is all they need, and we should be able to accommodate
> that.
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 :)

Best regards,