> 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, Fine! > 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 one-by-one. > 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, Konstantin.
