Vladimir Prus wrote:
On Monday 16 June 2008 20:08:57 Pawel Piech wrote:
I have two follow-up questions.
1. Do you consider this desirable to change the selected thread in UI when user types
"thread XXX" in console? If we want main UI and console to have the same notion of
the current thread, it seems the right thing to do.
I agree.
2. Suppose the current thread selected in UI is thread 1. User types, in CLI console,
"thread 2". The command is sent to GDB. We're in non-stop mode, and at this point,
some other thread stops -- let's say thread 1. I presume DFS will try to get
some information about this stopped thread -- let's assume it sends
a single -stack-list-frames.
- Assuming "thread 2" does not emit any notifications, will this cause DSF to
fail to emit -thread-select 1 before -stack-list-frames?
- Assuming "thread 2" does emit notifications about thread change, and DSF handles
such notification, is it guaranteed that the decision whether to send -thread-select
before -stack-list-frames is made only after "thread 2" is processed by GDB?
- Volodya
Without GDB notifications, parsing CLI commands is the only solution I can think of.
But with parsing only, this still leaves DSF-GDB broken wrt to user-defined commands as you pointed out above.
I have never used GDB from the command line, so my assumption that we could parse the
CLI commands to detect thread switches may have been rather naive. Your use case of user-defined commands
is certainly one I haven't thought of. A notification from GDB when the selected thread
changes would help, although to use them DSF-GDB would have to add special handling of CLI commands
to force it to wait for this event before sending another command (either CLI or MI).
Okay, so the conclusion appears to be that it's best if GDB emit notifications when thread changes.
And if GDB does so, then DSF should be modified to avoid sending more commands to GDB until the
previous CLI command is done executing, and therefore all notification from it were processed. Right?
You point about multiple windows is a tricky one. If we have two windows, both in debug perspective,
and we type "thread 2" in GDB console in one window -- do we want to change selected thread in
UI in just one window? I think we do want it, and it requires just:
- Making sure GDB emits the notification even if we're trying to select the same thread
as already selected
- Making sure the notification from gdb is associated back to the CLI command, and therefore
to specific GDB console
- Hooking that GDB console to DebugWindowContextService
Seems correct?
BTW, which code path actually handles CLI commands. IIUC, GDB console is created auto-magically
by ProcessConsoleManager whenever the GDB process is added to Launch. Where is DSF hooked into
that console?
- Volodya
Hmm.... The eclipse console is a view which uses the stdio channels of
the process object provided by the debug model. The GDB CLI
functionality: converting user-entered text into CLI commands and
interpreting the output is done within the debug model. So this logic
is not and cannot be aware of the currently selected UI context. If
multiple console views are open (in multiple windows or not) they will
be sharing the same IO channel and the same CLI session.
So, if we want to have the active context in the CLI console
synchronized with the active context in the window, we will need to
write some agent at the UI level which monitors the window selection
and emits the necessary thread and stack commands, into the console.
To avoid consoles in multiple windows from clashing with each other, we
would need to make sure that this agent is active only if the window is
active. I agree all of this is pretty messy, but the multiple windows
(and multiple-context debugging in general) really does complicate
things.
I think at this point, I agree that having GDB emit some kind of
=thread-selected notifications in response to CLI commands is the best
approach.
Cheers,
Pawel
|
