|Re: [dsdp-dd-dev] DSF design question|
Vladimir Prus wrote:
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.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
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.
Back to the top