This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI: is target running


 > > Yes, I think it should.  I have made changes to GDB, based on Apple's work,
 > > that makes GDB run asynchronously.  This means that the state of the
 > > inferior is reported regardless of whether the command executed was from MI
 > > or CLI.
 > 
 > Cool. But what does "asynchronously" means, exactly? 

I'm not the expert, but I can tell you what I understand by it.  Basically GDB
can accept further input even while the inferior is running.  I guess that the
output of some commands will depend on the timing, but others won't - I'm not
sure of the full implications.

In terms of the code, target_can_async_p () is true and with MI, for example,
GDB picks up mi_exec_async_cli_cmd_continuation to print the *stopped record,
even with CLI commands like "run".  But its probably better to let the code
speak for itself when the branch is created.

By giving each MI command a token number, it can be paired up with its output.
There's no need to have the concept of a queue, and so I think the front-end
is less likely to get confused.

As far as I know, asynchronous operation fits in with the general aims of the
GDB community, but it is certainly not something that I can implement on my
own.  So I can't say for sure that it will happen, but just that I would like
it to happen.

Nick


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]