Re: GDB Console

[Venkatram Tummala <venkatram867 gmail com>]

On Thu, Oct 14, 2010 at 1:49 AM, Dodji Seketeli <dodji seketeli org> wrote:
> 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.

I personally feel that users would like to have a CLI command
interface that is already familiar to them rather than introducing
them to new command interface. Personally, i won't have concerns
adapting to a new command interface but if we are concerned about
increasing the usage of nemiver, this disadvantage will definitely
will be a blocker in my opinion.
>
> 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/

This will work for me. As a user, i would definitely like this option.
>
>> 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?

Hmmm...Lack of a GDB CLI feature in nemiver is not something i am
worried about. Being a command line junkie, i still prefer doing some
things on the CLI rather than the GUI. For ex. Everytime i need to set
a breakpoint in a file that is not yet opened in the nemiver
workspace, i would prefer using the CLI to set it rather than using
the Set Breakpoint GUI window. Besides, some minor issues like using
CLI as a hex calculator etc. aren't available.
Its not to say that I hate GUIs in general. O'wise i shouldn't be
using nemiver in the first place. I would definitely love to have the
best of both worlds in a single convenient package.

So, its not about the *lack of a feature*, rather its just about
personal preference I would say. Thanks a lot for the info.
>
> 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
> _______________________________________________
> nemiver-list mailing list
> nemiver-list gnome org
> http://mail.gnome.org/mailman/listinfo/nemiver-list
>