Re: Roadmap beginnings

[Phil Muldoon <pmuldoon at redhat dot 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