public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Phil Muldoon <pmuldoon@redhat.com>
To: tromey@redhat.com
Cc: Frysk List <frysk@sourceware.org>
Subject: Re: Roadmap beginnings
Date: Fri, 11 Jul 2008 22:48:00 -0000	[thread overview]
Message-ID: <4877E322.1090707@redhat.com> (raw)
In-Reply-To: <m3bq14dwp3.fsf@fleche.redhat.com>

Tom Tromey wrote:
> I want to start discussion about the roadmap now, even before we've
> resolved a few major questions.  Initially I was hoping to defer this
> until we'd dug into the gdb question a bit, and settled the various
> licensing issues.  However, email yesterday from Keith showed me that
> these aren't independent -- some choices we make here may affect the
> outcome of those other decisions.  (More on this below.)
>   

I must admit to difficulties in reconciling this email chain with the 
"Changes" email chain, especially as I don't think the "Changes" email 
is done yet. I kind of wish the roadmap discussion had not so much focus 
on: "GDB or not to be GDB". But if this is the way of things, then so be 
it. I do feel like I am rewriting the same email over and over, but in 
different ways. Sorry to sound a bit frustrated here.

> So, what does "best C++ debugger" mean?  Naturally, I don't have a
> full list.  But, I have start -- please help add to this.
>   

Scripting. If a modern debugger cannot support this then it will just be 
a reimplementation of a monolithic debugger + wire protocol. We already 
have one of those, and I've already written many words on the pros and 
cons. Can we make GDB scriptable? If we can, how much work is it.? Ditto 
for Frysk.

> There are a few concerns folks have raised about what does not appear
> in the goal -- for example, cross debugging, or support for multiple
> languages, or remote debugging.  While I think these things aren't
> directly on our wish-list, I think these sorts of things can be
> addressed with good design.  We don't want to shoot ourselves in the
> foot.
>
> One possible exception here is that, AFAIK, Red Hat only cares about
> ELF targets.
>   

Yes, agreed.

> #1 is pretty much understood, I think.  Setting aside specific
> complaints about MI, a possible drawback I have heard is that this
> increases latency for debugging operations.  I haven't seen any
> measurements of this, though.
>   

There are huge, well documented debates on out-of-process/in-process 
debugging and wire-protocols. I will not trot them out here except 
mention that even the best, most efficient, wire protocol will be 
working out of band.

> #2 has several nice qualities, which I won't enumerate here.  In order
> to behave sanely as a library, the debugger does require a nicer
> kernel API than ptrace+wait; but this is being worked on already.
>
> However, this approach does put more constraints on the licensing.  In
> particular, GPLv3 would be a bad choice, as (I believe, IANAL) it
> would prevent library use in Eclipse.
>
> This in turn would impact our ability to reuse code from gdb.  I have
> had my eye on a couple gdb modules as good candidates for reuse: the
> macro expansion code, and perhaps the disassemblers.  (I'm not a gdb
> expert; if you know of other modular, reusable bits, I'd like to hear
> about them.)
>   

I'll be perfectly blunt here. If a less-free license is beginning to 
impinge upon the desirability of a "more-free" license we wish to use, 
lets should stop and think.

> Also, if #2 is a strong requirement -- if we really believe that #1 is
> a non-starter -- then that would essentially rule out working on gdb.
> I say this based on my belief that gdb is not a good candidate for
> librarification.
>   

#2 is (of course, imo) the prime reason for this project. I believe 
scripting requires an api/library approach, but would be happy to be 
proven otherwise ;)

Regards

Phil

      parent reply	other threads:[~2008-07-11 22:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-11 19:53 Tom Tromey
2008-07-11 20:56 ` Jan Kratochvil
2008-07-11 21:37   ` Tom Tromey
2008-07-11 21:54     ` Daniel Jacobowitz
2008-07-11 23:11   ` Kris Van Hees
2008-07-11 21:53 ` Daniel Jacobowitz
2008-07-14 16:34   ` Tom Tromey
2008-07-14 16:45     ` Daniel Jacobowitz
2008-07-14 16:58       ` Phil Muldoon
2008-07-14 17:09         ` Daniel Jacobowitz
2008-07-14 17:19     ` Ian Lance Taylor
2008-07-14 17:34       ` Daniel Jacobowitz
2008-07-14 18:04         ` Tom Tromey
2008-07-14 18:12           ` Daniel Jacobowitz
2008-07-14 18:11         ` Ian Lance Taylor
2008-07-14 17:35       ` Tom Tromey
2008-07-14 18:13         ` Ian Lance Taylor
2008-07-22 20:29   ` Debugger Work (Was: Roadmap beginnings) Tom Tromey
2008-07-11 22:48 ` Phil Muldoon [this message]

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=4877E322.1090707@redhat.com \
    --to=pmuldoon@redhat.com \
    --cc=frysk@sourceware.org \
    --cc=tromey@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).