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 query questions



On May 30, 2006, at 11:54 AM, Bob Rossi wrote:


On Tue, May 30, 2006 at 11:40:51AM -0700, Jim Ingham wrote:
Seems like having a callback in your parser to handle async messages
from gdb represents cleanly what is going on.  You haven't gotten a
completed MI command yet, and you're not ready for another MI
command.  But gdb is asking on the side for more input.  Seems like
making the two cases look the same is more likely to cause trouble.

I undstand, and sort of agree with you. However, things get slightly
worse from my perspective. I've designed my FE thus far to behave like
this:
- It is always looking for data from GDB to assemble MI output records.
- It will send only a single GDB command at a time.


With that in mind, my FE assembles an MI output record, and then sends
it up the chain to be looked at more specifically. However, with this
callback-in-the-middle scenario, my FE will have to be retrained to
handle partially returned MI output records.

Does this seem acceptable to you?

For instance, the annotate=2 looks like this:
    pre-prompt
    (gdb)
    prompt
    b A::func

    post-prompt
    [0] cancel
    [1] all
    [2] A::func(float) at overloaded.cpp:8
    [3] A::func(int) at overloaded.cpp:7

pre-overload-choice

overload-choice

I think the overload choice is as much a prompt as any other command. I'm
not exactly sure why you think it's a "special" input from the user.

I thought Daniel already answered this. It's not prompting for MI input, which is what the ordinary prompt does, it's just trying to slide some information to the CLI interpreter under the covers. As such it is very different from the ordinary prompt. You also don't have a completed MI output at this point - you haven't seen the matching ^done or any other appropriate command terminator - so in any case you are going to have to deal with partial MI output.


I also like this =read-one-line thingie, because it makes it explicit what's going on, namely something other than the MI is trying to read one line of input. So the FE should solicit a line of input from whoever it's getting that from in the command that caused this message to be delivered, and send it on...

Jim


I do see your point about the way your FE does this, however, do you see
my point here?


Thanks,
Bob Rossi


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