From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27941 invoked by alias); 11 Jul 2008 21:53:19 -0000 Received: (qmail 27930 invoked by uid 22791); 11 Jul 2008 21:53:18 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Jul 2008 21:52:46 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 7F4EA98415; Fri, 11 Jul 2008 21:52:44 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 4DB6598376; Fri, 11 Jul 2008 21:52:44 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KHQXj-0008TN-AJ; Fri, 11 Jul 2008 17:52:43 -0400 Date: Fri, 11 Jul 2008 21:53:00 -0000 From: Daniel Jacobowitz To: Tom Tromey Cc: Frysk List Subject: Re: Roadmap beginnings Message-ID: <20080711215243.GA30836@caradoc.them.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2008-05-11) 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/msg00026.txt.bz2 On Fri, Jul 11, 2008 at 01:53:28PM -0600, Tom Tromey wrote: > So, what does "best C++ debugger" mean? Naturally, I don't have a > full list. But, I have start -- please help add to this. Thanks for posting this - I think it's an enlightening question. Let me categorize these briefly: > 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.) It does a not half bad job, and specific problems with it are fixable. As for ultimate correctness and completeness, I have serious doubts that it is feasible - and I also doubt it would see enough use to justify the enormous investment. Prove me wrong and we'll merge it :-) > * 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. I'd call this a small project; only weeks of work to fix. > * Pretty-printing of STL containers and other C++ objects. This is a bigger project, but as Tom certainly knows GDB is solving it already. > * 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. Small, maybe midsized GDB project; dependent on a larger project in the compiler to generate useful information. This is a recurring theme; GCC's symbolic debug info is not adequate. Anyway, the trend I wanted to demonstrate: these are straightforward incremental additions to GDB. I'll sit back now and see what else comes up in the discussion, and if any of it has a fundamentally different character. I'm not convinced that it will or that it won't. > One possible exception here is that, AFAIK, Red Hat only cares about > ELF targets. As Ian said in his talk, ELF is a wonderful format used by almost all of maybe 5% of programs. If you're going to be ELF-centric, you lose Windows and OS X native debugging - and that's a big user base, even if not directly RH customers. So (stating the obvious here, I know) keep some kind of abstraction layer on file formats, even if it makes other things look like ELF :-) > #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 is a lot of room to optimize the existing performance of GDB/MI (and other GUI-reaction-time sensitive areas of GDB), plus the protocol is generally pipelining-friendly. Without numbers, I find this hard to credit. I've seen people hold CDT up as an example of this problem. I'm not personally involved with Eclipse development, but my understanding from others is that CDT is slow because CDT is slow, not because MI is slow. DSF is expected to be much faster. > * 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. I think it has little or nothing to do with the debugger; the easiest implementation would be a remote protocol implementation in valgrind. > It would also be worth doing a bit of competitive analysis of the > leading closed-source debuggers out there. I haven't done this, but my expectation is that more of the differentiation is in the GUI capabilities than the back end capabilities. If you want to talk about a modern, open-source, widely developer accessible debugger, I think you need to consider GDB + Eclipse as a combination, not GDB alone. You can argue about what goes after the plus sign. -- Daniel Jacobowitz CodeSourcery