Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-dd-dev] DSF design question
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

Back to the top