Re: GDB Console

[Dodji Seketeli <dodji seketeli org>]

Hello Fabien,

Fabien Parent <parent f gmail com> a écrit:

> The goal is to have a console as similar as the real GDB as possible
> and with the least effort required to implement it, to do that I will
> just send the raw query to GDB/MI and print its output.

Hmmh, I might disagree with this part.  I'd prefer the goal to be along
the lines of "Being as close as reasonable to GDB, but no closer".  At
least for a beginning.

What I mean by this is, said bluntly, the console is meant to be a
Nemiver console, not necessarily a GDB console.  If tomorrow there is a
GDB v2 out there, or another debugging engine that comes as a library,
or whatever, we should be able to just write a new implementation of the
IDebugger interface for that new "backend" and the command console
should just work with no change.  I don't know if that'll happen any
time soon, but I think this is a right mental model to have to stick
ourselves to having a well defined interface to GDB.

Doing the right choice, sort of, rather than the easy one.

So I think all the commands should be re-written in terms of IDebugger.
Another nice side of effect of that would be to have a scripting
interface there as well.  The scripting interface would e.g, just wrap
IDebugger, and when you send a command using the console, a script could
listen and react to the IDebugger signals we already have, and could
even intercept the commands before they go out the backend (which
happens to be GDB today).  Who knows, maybe the good thing to do would
be to actually wrap IDebugger in a scripting language first, then write
the console commands in that scripting language?  I don't have a strong
opinion on this particular part right now; I just wanted to mention it
to make my point of "Any talking with the debugging engine should go
through IDebugger".

Heck we could even re-write the graphical actions implementation to use
the commands of the console (that will be written in terms of IDebugger)
instead of using IDebugger directly.  That way, the user could see what
console command corresponds to the graphical action she has just
performed.  That could be useful also to save some commands into a
textual form and make Nemiver read them back and execute them later.

> For few commands (ex: everything related to breakpoints), nemiver
> needs to get a feedback from GDB that it understand, this is why there
> will be some kind of filter that won't send the raw command to GDB and
> instead use the IDebugger interface (these commands might have some
> limitation compared to the real GDB command because of the often more
> limited GDB/MI interface).

If all the communication with the backend uses IDebugger, we wouldn't
have any particular case of this sort.

> if you have suggestions I'm open to commentary.

There you go.  :-)

Thank you for working on this topic.  It's hot, and I like it.

-- 
		Dodji