From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2523 invoked by alias); 11 Jul 2008 19:53:50 -0000 Received: (qmail 2513 invoked by uid 22791); 11 Jul 2008 19:53:49 -0000 X-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_05,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 19:53:32 +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 m6BJrUXb016900 for ; Fri, 11 Jul 2008 15:53:30 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6BJrTFS018757; Fri, 11 Jul 2008 15:53:29 -0400 Received: from opsy.redhat.com (vpn-10-60.bos.redhat.com [10.16.10.60]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6BJrS0Q022851; Fri, 11 Jul 2008 15:53:28 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 531DC88808C; Fri, 11 Jul 2008 13:53:28 -0600 (MDT) To: Frysk List Subject: Roadmap beginnings From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Fri, 11 Jul 2008 19:53:00 -0000 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00023.txt.bz2 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.) So, what does "best C++ debugger" mean? Naturally, I don't have a full list. But, I have start -- please help add to this. The baseline is gdb doing native debugging of a C program. I think it doesn't make sense to do anything less than this. This covers the usual stuff: breakpoints, watchpoints, step, next, print. There's a bunch of specific C++-debugging things that, afaik, gdb does not do very well: * Correct expression parsing. (Though I am told this is extremely difficult to impossible in the general case.) * Nice user experience when debugging with exceptions. E.g., if you 'next' over a function call, and the function throws an exception to a "higher" frame, the program should stop there. * Pretty-printing of STL containers and other C++ objects. * Smarter demangling of names. The ideal would be that demangling yields the name that the user wrote in the source -- meaning, compressing the output by omitting default arguments, and respecting typedefs. Scalability appears twice on the requirements list -- scaling to large programs and scaling to many threads. The latter is addressed, I think, by the non-stop debugging design already in frysk (and being added to gdb). I am not sure precisely what problems gdb has with the former; however I am told there is a BFD scalability issue when moving to multiple processes. 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. Connecting to a GUI is turning out to be a driver for some decisions. I have heard some dissatisfaction expressed about MI. There seem to be two schools of thought: (1) use some wire protocol to separate the GUI from the debugger, or (2) use a library. #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. #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.) 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. This decision is not as simple as it may seem. For example, it would likely restrict what "intelligence" we could put in to the CLI, as (I imagine) the library users would largely bypass the CLI in favor of direct API access. As I mentioned in the earlier note, we want to provide scripting support based on Python. From our perspective, Python is the best choice because it is popular and generally acceptable. I think if we achieve all of the above, we will have made a solid C++ debugger. For it to be "best in the world" I think we will need to raise the bar a bit. A few ideas I've heard kicked around: * Reverse-time debugging. (There are some gdb patches for this.) * "Smart" multi-process debugging, whatever that means. The blue sky idea I have heard here is to be able to step into a remote procedure call and start debugging the other side. (It isn't clear to me that the implementation effort here is worth the payoff.) * Multi-language debugging where one of the languages is a scripting language. Offhand it seems to me that this is largely a CLI issue -- filtering stack traces, rewriting expressions to look into interpreter data structures, avoiding a direct 1:1 mapping between a user's notation for a {break,watch}-point and the internal objects that this creates, etc. This one really has nothing to do with C++ per se. * Some kind of systemtap integration, as Eric has asked for. I'm still very unclear on what this would look like. * The ability to debug a program being run under valgrind. This is mildly related to the debugging-a-scripting-language question, but also (I imagine) probably requires changes on the valgrind end. * Fix-and-continue. (Though this appears to be something that sounds cooler than it actually is.) It is kind of unfair of me to hold out the blue-sky stuff, since I think we will have our hands full on just the essentials. But, I wanted to get people thinking about this a bit more. Also, some of these have come up repeatedly during our internal discussions. It would also be worth doing a bit of competitive analysis of the leading closed-source debuggers out there. Tom