From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1235 invoked by alias); 11 Jul 2008 22:48:28 -0000 Received: (qmail 1225 invoked by uid 22791); 11 Jul 2008 22:48:27 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Jul 2008 22:48:10 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6BMm7XT022565 for ; Fri, 11 Jul 2008 18:48:07 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6BMm8D0022369; Fri, 11 Jul 2008 18:48:08 -0400 Received: from localhost.localdomain (vpn-6-47.fab.redhat.com [10.33.6.47]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6BMm67L023491; Fri, 11 Jul 2008 18:48:07 -0400 Message-ID: <4877E322.1090707@redhat.com> Date: Fri, 11 Jul 2008 22:48:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: tromey@redhat.com CC: Frysk List Subject: Re: Roadmap beginnings References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00028.txt.bz2 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