Re: [dsdp-dd-dev] DSF design question

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

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.

>  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?

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.

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