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 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 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]