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.
Cheers,
Pawel
|
