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

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

On Wednesday 18 June 2008 20:27:32 Pawel Piech 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

For my education -- which methods are responsible for those conversion of 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.        
>  
>  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.

This sounds complicated. Is there no way, in the code that handles user-entered text in
console to:

1. Figure which console view has generated that text
2. Figure, from that, which main window is that
3. When GDB response, change debugging context only in the window found in (2)

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

OK. I've posted a description of how threads should work in MI to the gdb mailing list,
eariler today.

- Volodya