Re: GDB Console

[Dodji Seketeli <dodji seketeli org>]

Thank you for chiming into this discussion.  I think discussing this
kind of thing ahead of implementing does have a lot of value.

Tom Tromey <tromey redhat com> a écrit:

> I think you should pick between two alternatives:
>
> 1. Implement a Nemiver CLI that is very different from the GDB CLI, or
>
> 2. Implement the console as a pass-through to whatever debugger is
> underneath.
>
> Trying to implement something that is similar to GDB seems like it will
> end badly -- GDB will change, and Nemiver will continually be playing
> catch-up.
>
> My view is that #2 is probably preferable, but YMMV.  One attraction of
> #1 is that the GDB CLI is not very well-designed.

The way I see things is that the Nemiver CLI will be different from the
GDB CLI anyway.  For instance, it seems to me that it's of little
relevance to have the exact GDB "list" command, when you can otherwise
read the source code in a graphical way today already.

On the other hand, some users have asked for commands that would, for
instance, make Nemiver find the source code for a given symbol and
scroll appropriately to let the user read the code of that function.  I
guess this would need some work outside of GDB (in Nemiver) to
implement.

And there will a corpus of obvious commands like next, step etc, for
which I see little value in naming differently from GDB.  For instance,
the equivalent commands in other debuggers like JDB or the python/perl
debuggers are quite similar to those that can be found in GDB.

>From a pure implementation point of view, I think that if we write the
Nemiver CLI in terms of the IDebugger interface, we still have the
choice to just implement particular commands as pure GDB CLI pass
through, rather than using MI.  We have done this in the past, and we
still do this for some commands.  In other words, using GDB/CLI or
GDB/MI is a choice we can make on a case by case basis.  And it seems
interesting to me to keep that possibility to choose.

But still, regardless of the cost of implementation, I lean towards
thinking that using the existing Nemiver/MI infrastructure to implement
Nemiver CLI commands that implement features that we /already/ have
graphically is a better design.  I could expand more on this if you
want.

As for the catch-up game, we are deep into it already.  :-)

> Fabien> For few commands (ex: everything related to breakpoints), nemiver
> Fabien> needs to get a feedback from GDB that it understand, this is why there
> Fabien> will be some kind of filter that won't send the raw command to GDB and
> Fabien> instead use the IDebugger interface (these commands might have some
> Fabien> limitation compared to the real GDB command because of the often more
> Fabien> limited GDB/MI interface).
>
> Newer versions of GDB now emit MI async events when a breakpoint is
> created via a CLI command.
>
> We'll add new async events as needed to expose to the MI client other
> state changes caused by the user.  File bugs if you know of missing
> ones.

Yes.  I still need to support many of the existing async commands ;-)
You said catch-up? :-)

-- 
		Dodji