Vladimir Prus wrote:
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.
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).
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....
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?
...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.
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 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.
Cheers,
Pawel
|