From: Andrew Cagney <cagney@redhat.com>
To: frysk <frysk@sources.redhat.com>
Subject: frysk vs ? vs gdb++ vs gdb
Date: Wed, 16 Jul 2008 15:28:00 -0000 [thread overview]
Message-ID: <487E13AE.7000002@redhat.com> (raw)
In reading over the various discussion's its not been clear to me what
exactly the proposals are, and how each fits in. In addition, while all
efforts have similar long term goals, I think it is useful to compare
based on more immediate expected deliverables - say over a 1-2 year time
frame.
With this in mind, I've tried to construct a table that gives a
relatively sharp distinction between choices. Of course reality is more
fluid.
Frysk: the existing frysk project
?: Red Hat's new debugger as first proposed on the Frysk list
GDB++: An implementation of GDB in C++
GDB: Existing GDB.
A "?" indicates positions that seem to be evolving.
Frysk ? GDB++ GDB
focus: thread/proc C++ C++ ?
linux linux ? ?
user DESKTOP GDB GDB GDB
language Java C++ C++ C
Eclipse DSF Plug Plug? MI MI
Licence V2+ V3+ V3 V3
EXCEPT EXCEPT
Owner RH/OR/IBM/+ RH? FSF FSF
Design Frysk Frysk? GDB GDB
Frysk?
Code Frysk frysk? GDB GDB
developers new RH GDB GDB
GDB? RH?
Tech Edge: strong O-O
thread/proc? unwind
type/location testsuite
? mi
gdb/cli
remote
isa's
other languages
?
focus/user: This is the groups intended user base and initial most
critical feature; and the likely source of users.
language: the project's principal language; all projects have plans to
hadd an interpreter for something like Python.
Eclipse: How the tool will integrate into eclipse; a plugin requires an
eclipse compatible licence (such as GPL+EXCEPT).
Licence: For instance, if GDB code is used, then the licence is pure V3.
If it is to be an ecplise plugin then pure V3 cannot be used.
Owner: Who will own the code base.
Design: Where the architecture comes from; its been suggested that
aspects of frysks architecture be transferred to gdb.
Code: Where the bulk of the initial code base comes from. For this new
debugger, while the design can be drawn from Frysk, the bulk of the
implementation would be new.
developers: from where developers will likely be attracted or drawn
tech edge: where the existing code base has what I think is a clear
existing technology advantage
reply other threads:[~2008-07-16 15:28 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=487E13AE.7000002@redhat.com \
--to=cagney@redhat.com \
--cc=frysk@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).