|Re: [dsdp-dd-dev] DSF design question|
Vladimir Prus wrote:
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).On Monday 05 May 2008 19:39:42 Pawel Piech wrote:The current thread problem in the console is indeed a problem not just in non-stop mode but even with current DSF-GDB implementation. I filed a bug for it: https://bugs.eclipse.org/bugs/show_bug.cgi?id=192742 quite a ways back, though it's one of many problems with the GDB CLI console. The proper DSF-style solution I believe is to have the console itself track its current thread-id and stack frame. Just like any other client to the command interface, the console should supply the context that it wants its commands executed in. As far as I know there are only a couple commands that switch the current context in the CLI interface so the implementation of the state tracking could be done by parsing the commands its sending to GDB and looking for "thread ...", etc.Well, this will cause user-defined commands that switch threads to break. Fortunately, patches to make GDB notify when current thread changes are been discussed on gdb-patches@ now. But actually, I think that UI and CLI console should have the same notion of selected thread and frame -- having two different selected threads will be extremely confusing.
Unfortunately for the GDB integration, Eclipse cannot have a single thread in the UI, because the user can open multiple Wokrbench windows and interact with the same debug session from both windows. DSF-GDB treats the currently selected thread in GDB as only a protocol state and this state is not exposed in any way in the ui....
...except of course for the console. I agree with Marc that the console integration is broken. Currently when user sends thread and stack select commands he changes the protocol state without the knowledge of the command control which will lead to various evaluation errors from other services. My suggestion in this email from May 5th is that the console itself should parse the CLI commands and track its active thread, so that for all the CLI commands it sends, the console would include the appropriate thread DM context, which would in turn cause a protocol state change in the command control.On the down side, this solution could actually be somewhat counter productive, because it is useful to have the currently selected thread and frame in the console match the currently selected context in Debug view. We can solve this by having the console listen to the currently selected context and explicitly emit "thread ..." and "frame ..." commands to the console.Why is that necessary? If there's a single 'current thread' per session, then the next time you send a CLI command, if the UI current thread is different from GDB's current thread, -thread-select will be issued by the same mechanism that issues -thread-select for MI commands. Or you mean just adding "thread XXX" to the text in console to indicate the thread change to the user, without actually sending the command to GDB?
In my suggested solution, the console would track its own current thread, so to keep in sync with the UI (and not necessarily the protocol state), the console would need to switch its active thread in response to UI events.
I agree.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.
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.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
Back to the top