[Qt-creator] MPI debugger plugin
André Pönitz
andre.poenitz at mathematik.tu-chemnitz.de
Thu Aug 15 00:00:19 CEST 2013
On Wed, Aug 14, 2013 at 11:18:55AM -0700, Mohammad Mirzadeh wrote:
> > We already have the ability to run multiple "debugger engines" in
> > parallel. There are, however, currently only two features that take
> > advantage of that. The first is the "Snapshots" feature, which allows
> > you to take "Snapshots" of a running process (essentially core file that
> > are owned by seperate engines) and switch between those snapshots
> > and the live process using the Snapshots view.The second
> > mulit-engine feature is the mixed qml/c++ debugging consisting
> > of three engines running in parallel - one "master engine" essentially
> > multiplexes between a qml/js debugger engine and a c++ debugger
> > engine talking to gdb or cdb. Going from the Snapshot feature to
> > proper MPI support should be possible.
>
> Yeah I remember snapshot was suggested to me before, and while its
> better than separate sessions, I have couple of issues with it. One
> is, I'd rather have something that will launch and debug the
> executable from inside QtCreator rather than running it in terminal,
> pausing it, and then attach the debugger. The other one is I remember
> when putting breakpoints (after attaching) it would only work on the
> current snapshot and not the rest.
The current approach is that engines are asked whether they would like to
handle a breakpoint, and the first one that accepts takes control of the
breakpoint. This covers the two current use cases: in the snapshot case,
only the engine with the living process accepts breakpoints at all, and
in the mixed qml/c++ case the qml engine accepts only breakpoints in qml/js
code and the c++ engine everything else.
It does not cover your MPI case, where you like to have the breakpoint
"multiplied" and installed in all engines, but changing the approach from
"the first gets it" to "everybody interested gets a copy" is not hard,
and would then cover the existing two and the mpi case.
> How would you suggest I go about changing snapshot feature. I'd like
> to have something like this:
> 1) A simple pop up window where I can set the number of processes that
> code should be run on.
> 2) Given the number, QtCreator should invoke mpirun to run the
> executable, and possibly pass all command-line options.
I think that can be integrated into the run configuaration properly.
Assuming you can really _start_ gdb with mpirun (haven't tried) this
could be something like the following:
- add an int DebuggerRunConfigurationAspect::mpiJobCount member
- add an DebuggerStartParameter::mpiJobCount member
- add a line edit or spinbox to DebuggerRunConfigWidget handling
DebuggerRunConfigurationAspect::mpiJobCount
- in DebuggerRunControlFactory::create copy the count from the
aspect to the start parameters
- in GdbEngine::startGdb augment the startup call by whatever
mpirun -n <count> you need.
This should be around 100 or 150 lines of code.
> 3) Then It should attach gdb to each separate process and show that in
> window like snapshot where it would be easy to switch back and forth
> between processes
> 4) Finally It should be possible that a breakpoint be applied to all
> running processes
Doing that properly would mean to break the 1:1 relationship between
BreakpointParameters (the specification of the breakpoint) and
BreakpointResponse. Best approach would be to simply store the
BreakpointResponse in the DebuggerEngine instead of the BreakHandler.
So BreakHander::setEngine would go, and in In DebuggerEngine::
attemptBreakpointSynchronization the handler->setEngine(id, this)
call would instead update the then-local BreakResponse data.
The BreakView would ask the currrentEngine() for data (similarly
to what the StackView etc do), and only fall back to the global
BreakModel for unclaimed "pending" Breakpoints.
This should not need much new code, but requires a bit of shuffling.
Andre'
More information about the Qt-creator
mailing list