From: Elena Zannoni <ezannoni@redhat.com>
To: Bob Rossi <bob_rossi@cox.net>
Cc: gdb@sources.redhat.com
Subject: Re: obsoleting annotate level 2
Date: Tue, 04 Feb 2003 15:49:00 -0000 [thread overview]
Message-ID: <15935.57871.225622.319870@localhost.redhat.com> (raw)
In-Reply-To: <20030204124435.GB2565@white>
Bob Rossi writes:
> Hi,
>
> I have been writing a front end to gdb called cgdb. It depends on gdb's
> annotate level 2 feature. This project can be downloaded at
> cgdb.sourceforge.net. Before that it was hosted at tgdb.sourceforge.net.
>
> It is a curses front end to gdb that is intended to be lightweight and
> responsive. I originally wrote cgdb because I use gdb, sometimes for
> several hours, during the day at work. We use GNAT's version of gdb
> which seems to be behind GNU ( As far as version and features ).
>
Interesting, I don't know if you are aware, gdb has already a curses
interface. configure gdb with --enable-tui and invoke with --tui.
Documentation is at:
http://sources.redhat.com/gdb/current/onlinedocs/gdb_22.html#SEC197
Would it make sense to unify the efforts? Even though i see you want a
completely separate UI.
elena
> I decided to make it a curses front end because there are many times
> during the day when I ssh into a window's box using cygwin.
>
> At the time I started developing cgdb ( about 8 month's ago ). I began
> looking into how to interface with gdb without losing any of the
> command line power. I began looking into how other debugger's did it.
> So I soon realized that xxgdb, ddd and gvd all used annotate level 1.
> I then did a little more research and discovered
> http://www.gnu.org/manual/gdb/html_chapter/gdb_21.html#SEC203 which
> encouraged me to use annotate level 2. Since even NOW, the manual says
> nothing about annotate level 2 being deprecated, but describes how to
> use the annotations.
>
> I used annotate 2 to interface to gdb for several reasons:
> 1. gdb-mi is not in older versions of gdb. Including GNAT's version
> of gdb ( which we use at work ). If I wrote a front end using this
> the gdb-mi feature of gdb, I would not be able to debug programs
> with GNAT, cygwin, red-hat, suse ... out of the box distributions.
> This seems UNACCEPTABLE.
> 2. gdb-mi does not have readline support at the command line.
> This is an important feature if the GUI wants to keep gdb's
> useful command line feeling 100%.
> 3. gdb-mi did not ( at the time ) support the CLI commands.
> 4. annotate level 2 gave much more information to the GUI over
> annotate level 1. Including:
> 1. When the user is interfacing with the readline library.
> 2. When the breakpoints need to be checked (instead of every time).
> 3. The prompt can change. the debugged program can output the
> string '(gdb) ' to stdout without breaking the GUI.
> 4. I was able to allow the user to communicate with the debugged
> program, no matter how the debugged program sets the terminal.
> ex. ( cbreak, raw ...)
>
> I feel that cgdb should be separated from gdb for several reasons:
> 1. cgdb should support a rich variety of options including
> 1. macro support
> 2. key bindings that do not have to be Emacs style
> 3. configuration file for syntax color support ...
> 4. regular expression searching
> 5. many more options that can make cgdb easier to use.
> 2. Users should not have to recompile gdb to get curses support.
> 3. I can write cgdb knowing nothing about the internals of gdb,
> without sacrificing the risk of bugs in gdb for a GUI.
>
> With these things in mind, I understand that gdb must move on. With or
> without cgdb. Eventually cgdb will support gdb-mi. My only claim is that
> gdb keep supporting annotate level 2 until it is ready to remove both
> annotate level 1 and 2.
>
> This way when other programs like gvd, ddd and xxgdb are rewritten to
> use gdb-mi and not annotate level 1, then programs like cgdb and
> possibly others can be rewritten as well. I know these programs will use
> gdb-mi when it is stable and ready. Util then, I don't think annotate
> level 1 or 2 should be removed since there are existing front ends to gdb
> that use them.
>
> I believe this is fair. In fact, I am even willing to support annotate
> level 2 if necessary. I know I have no association with GNU, but I would
> be willing.
>
> Thanks,
> Bob Rossi
next prev parent reply other threads:[~2003-02-04 15:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-04 12:44 Bob Rossi
2003-02-04 15:49 ` Elena Zannoni [this message]
2003-02-04 16:12 ` Peter Kovacs
2003-02-04 16:30 ` Elena Zannoni
2003-02-04 16:37 ` Bob Rossi
2003-02-04 17:10 ` Elena Zannoni
2003-02-04 19:48 ` Jim Blandy
2003-02-04 21:22 ` Nick Roberts
2003-02-04 23:01 ` Andrew Cagney
2003-02-04 16:41 ` Peter Kovacs
2003-02-04 16:46 ` Peter Kovacs
2003-02-04 17:16 ` Elena Zannoni
2003-02-04 19:53 Mike Mueller
2003-02-05 6:57 ` Jim Blandy
2003-02-05 20:04 ` Bob Rossi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15935.57871.225622.319870@localhost.redhat.com \
--to=ezannoni@redhat.com \
--cc=bob_rossi@cox.net \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox