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: asynchronous MI output commands


Daniel Jacobowitz wrote:

> On Sun, May 07, 2006 at 11:09:51PM +0200, Bjarke Viksoe wrote:
>> In my case I wish to submit several commands at once and slowly digest
>> the answer (over a remote line where the network round-trip is slow).
>> Using the <token> is clumsy and doesn't solve the problem of having
>> enough information to process the answer without keeping track of the
>> question. Since separate components handle the output autonomously, I had
>> to give up tracking a command-list, and instead had to make sure only 1
>> question was lingering - thus making the entire solution run much slower
>> than otherwise needed.
>> 
>> I found that commands that return "^value" result-records (such as
>> -var-evaluate-expression and -data-evaluate-expression) doesn't carry
>> enough information. I don't think a model where the entire command is
>> repeated in the output is a desirable design, but at least identifying
>> the question-type and its crucial parameters would suffice.
> 
> If I were writing a front-end, I would have an arbitration layer which
> sent questions to GDB and received answers.  The answers will come back
> one at a time, in the same order the questions were asked.  If you send
> two -var-evaluate-expression commands, you'll get back two answers, in
> that same order.
> 
> Am I missing something?  Is there a reason that this isn't enough?

For the record, that's basically what I have in KDevelop. There's command
queue, and commands are sent to gdb one-at-a-time, and responses come
exactly in the same order. Remembering the last issued command (i.e.
instance of GDBCommand class internal to KDevelop) makes it possible to
route the response back to the original command. 

I'm don't quite understand the problems being discussed in this thread. It's
not apparent why one has to know the type of the last command while
parsing, and if so, why remembering the last command is bad idea.

It's hard to believe that response from MI can be useful without knowing the
last issued command. Say, response from -data-evaluate-expression is
useless if you don't know what part of frontend wants that data --
evaluating expression is used in many use cases. So, you need to associate
extra data with commands anyway.

- Volodya



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