[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] I'm having issues extending dsf-gdb
|
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of dmsubs
> Sent: Wednesday, November 10, 2010 11:01 AM
> To: 'CDT General developers list.'
> Subject: [cdt-dev] I'm having issues extending dsf-gdb
>
> Hi,
>
> I am writing an extension to the GdbLaunch to launch our
> debugger. I have
> written a FinalLaunchSequence (by copy/paste the existing
> one) and have
> added some new Step()s to configure our target. These Steps
> use CLICommands
> to configure gdb as we need. I have this working.
>
> My problem is that the CLICommands seem to be sent to GDB
> asynchronously -
> without waiting for a response. In the 'gdb traces' console,
> I see my new
> commands like this:
>
> 7my-command1
> 8my-command2
> 9my-command3
>
> And then
>
> 7+my-output1
> 7+my-output2
> 7^done
> (gdb)
> 8^done
> (gdb)
> 9^done
> (gdb)
>
> Is there any way I can make the commands execute
> synchronously (i.e. wait
> for a response before moving on). For example, I need to
> modify step 8 in
> response to the response to step 7.
In the FinalLaunchSequence, most of the steps should be 'synchronous'
already. The RequestMonitor that triggers the next step only
gets its done() method called once the answer of the previous
step has arrived. If you look at the gdbtraces, you should see this,
up to the point where we start installing breakpoints.
For breakpoints, we ask the MIBreakpointsManager to trigger the
installation, and it has a loop where it sends all breakpoints
asynchronously and once all answers are received, is allows
FinalLaunchSequence to go to the next step.
So it really should be no problem for you to use a 'synchronous'
sending of commands. Just make sure that each step in the sequence
sends a single MI command.
Marc
