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

This is implemented by GDBCLIProcess extending AbstractCLIProcess, which in turn extend java.lang.Process.  There is also a separate module CLIEventProcessor (all in the org.eclipse.dd.mi.service.command package), which parses CLI commands and events and generates corresponding model events as needed.

 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)

Of course where there's a will, there's a way :-)  The current design of the CLI interface is based on the CDI-GDB debugger integration in the CDT project.  It re-uses the standard Eclipse console view, which also used by Eclipse to show the standard IO of many things including builds etc.  If it's important to someone to have a dedicated view for GDB CLI interaction, they could very well contribute such a view and not need to go through this somewhat awkward Process interface. 

To answer your question though, to point 1, there is no way for the model object to know which window the command came from.  There is a clean separation in DSF as in most Eclipse plugins between UI and non-UI components, and the AbstractCLIProcess doesn't even have access to the Window class in which the command was entered.  So to deal with issues in the UI, a component needs to be created at the UI level, hence my proposed agent which would be tied to the console view.

 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.

Thank you, it was much appreciated.

Back to the top