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 non-stop mode spec


Vladimir Prus wrote:
Pawel Piech wrote:

Vladimir Prus wrote:
Thanks for agreeing :-) Like I said, I have no idea of the complexity
of such a change. However, it seems to me that you should be able to
implement a simple protcol-state-tracking logic for both CLI and MI
protocols, and simply simulate the --thread option for commands that
don't supply one. This way you could have both the backward compatible
stateful protocol, and have the -thread option to override it on the
individual commands.
This might be actually a reasonable thing. On one thing, not switching
the current thread might be good for CLI. On the other hand, I still believe
that --thread is ultimately better solution for MI. Then, it might be best to
make GDB not to switch threads (benefiting CLI and stateful MI), and
also accept --thread for the benefit of newer MI clients.

Now there's the catch that --thread is already implemented and is rather
straightforward, whereas I expect some corner cases in implementing thread
that does not change. I think we'll first get the non-stop mode working
with --thread, and then look into making current thread not change.
(For avoidance of doubt, "then" means "immediately after" not "someday").
I think this would be an excellent compromise. If there is any kind of
a layering between the protocol interpreter and the underlying
functions, it shouldn't be too much of a stretch to add the state
tracking in the protocol interpreter layer.

This is one implementation approach -- add current thread in MI, and switch
GDB's global current thread to MI's current thread when executing any command.
This is not very hard, but won't help CLI. Another approach is to do the
same trick for CLI. Yet another approach is to make sure GDB never changes its global thread except internally, when it's guaranteed not to talk to user.
We'll see which approach is best.


Great!
BTW, for the clients that support both a UI and a command console it would be even even better if
CLI and MI maintained their own current thread and stack frame. This
would prevent the two interfaces from interfering with each other.

Oh, that's interesting idea. But, would it not be confusing if frontend shows certain thread and frame as current in UI, whereas commands in GDB console operate on some other thread?

It certainly could be confusing. Although in Eclipse DSF-GDB the UI selection is already decoupled from the MI protocol state. One elegant solution to this would be to allow the user to electively link the console view to the UI selection, where the linking implementation would explicitly write "thread" and "frame" commands into the console. But such a feature would require additional work on the client side.

Cheers,
Pawel
- Volody


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