Re: GDB Console

[Dodji Seketeli <dodji seketeli org>]

Hello Venkatram,

Venkatram Tummala <venkatram867 gmail com> a écrit:

> It would be great to have a GDB console to nemiver. I searched the
> nemiver mailing list & i saw that others were also interested in
> having this feature. Can we expect this feature to be implemented in
> any of the near future releases.

Yes, this is definitely something I'd be interested in seeing work being
done on. FWIW, it is bug
https://bugzilla.gnome.org/show_bug.cgi?id=604845

This does looks like a major task to undertake at the moment and here is
why:

In GDB land, users and programs don't speak with the debugger using the
same interface. the CLI (command line interface) is different from MI
(machine interface).

Nemiver (and most graphical debuggers using GDB that I know of) use MI
for a good reason. It's the interface that has been designed to interact
with programs.  The problem is when Nemiver issues a CLI command, it
doesn't get feedback on the MI interface. And not getting feedback means
Nemiver cannot update its state accordingly. E,g., if you modify the
state of a breakpoint using the CLI, Nemiver has way to know if that
state got eventually changed or not because it will not receive any
feedback on the interface it is using.

There are several ways to address this issue.

1/ Write a command line interpreter on top of the interface Nemiver is
   currently using.  Today, on top of MI Nemiver does have an API
   [called IDebugger] that abstracts away most of the details of the
   interaction with GDB. So I think we could write a command line
   interpreter on top of IDebugger. This has many interesting side
   effects:

   Each state change triggered by the command line interpreter
   can be tracked by client code using IDebugger directly and vice
   versa.

   The parsing and validation of commands would be done by Nemiver so
   error messages could be better integrated in the context of
   Nemiver. The messages could be properly translated by the same
   contributors who translate Nemiver today etc ...

   Good scripting integration. The scripting engine would have access to
   both the command interpreter, the IDebugger interface and also all
   the debugging specific widgets we have today.

   If tomorrow we write an IDebugger backend for something different
   from GDB we wouldn't have to change the implementation of the command
   line interpreter. It will just work on top of that new "debugger
   engine". In short, IDebugger make us consider GDB like "just a low
   level debugging engine". So code written on top of IDebugger should be
   somewhat reusable on another debugging engine.

   The main disadvantage I am seeing with this is that it takes a lot of
   work.

   Another disadvantage is that the set of commands exposed by Nemiver
   would be different from those of GDB. Personally I don't see this as
   a really problem because to me, Nemiver is more about providing a
   nice and consistent debugging experience in GNOME rather that being
   about exposing every little GDB feature one can think about. If a GDB
   command makes sense to be exposed in Nemiver verbatim, the no
   problem. If it doesn't make much sense in a GNOME environment then we
   ought to provide replace commands for it.

2/ Modify GDB so that CLI commands trigger MI protocol replies.  If this
   was done today, Nemiver could just let the user type free form GDB
   commands, send those to the GDB and we would still get MI protocol
   notifications about state changes.

   The main advantage of this is that it requires much less work on
   Nemiver side. The disadvantages are related to the fact that we
   wouldn't have many of the pros we get with 1/

> Atleast for me, Lack of GDB console is the only reason why i can't use
> nemiver as my full-time debugger.

This is interesting. Whenever I stumble upon a particular feature
missing in Nemiver but present in GDB CLI, I try to implement it in
Nemiver. So I'd be _really_ interested in hearing about what exactly the
GDB CLI provides you that we are lacking in Nemiver today. Can you give
us a couple of concrete examples?

IMHO Implementing those particular features in a graphical way could
enhance the user experience. Of course, I agree that we ought to provide
a command line interface too. I am just saying that the two ways should
not necessarily be mutually exclusive.

Thank you for raising this.

-- 
	Dodji

>  LocalWords:  Nemiver GDB CLI breakpoint API IDebugger versa backend