From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17729 invoked by alias); 22 Jul 2008 20:29:52 -0000 Received: (qmail 17720 invoked by uid 22791); 22 Jul 2008 20:29:51 -0000 X-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_05,KAM_MX,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; Tue, 22 Jul 2008 20:29: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 m6MKTTWT025395; Tue, 22 Jul 2008 16:29:29 -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 m6MKTSQf032651; Tue, 22 Jul 2008 16:29:28 -0400 Received: from opsy.redhat.com (vpn-10-116.bos.redhat.com [10.16.10.116]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6MKTSGO019379; Tue, 22 Jul 2008 16:29:28 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 6B0C6378245; Tue, 22 Jul 2008 14:29:27 -0600 (MDT) To: Daniel Jacobowitz Cc: Frysk List Subject: Debugger Work (Was: Roadmap beginnings) References: <20080711215243.GA30836@caradoc.them.org> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Tue, 22 Jul 2008 20:29:00 -0000 In-Reply-To: <20080711215243.GA30836@caradoc.them.org> (Daniel Jacobowitz's message of "Fri\, 11 Jul 2008 17\:52\:43 -0400") 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/msg00060.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> Anyway, the trend I wanted to demonstrate: these are Daniel> straightforward incremental additions to GDB. Thanks for this note. Red Hat is going to put its "best C++ debugger" efforts into gdb. Naturally, this was not an easy decision. There are two basic reasons that caused us to revisit gdb. One reason comes from Daniel's email: our concrete wish-list is a series of deltas to gdb; of these some are pretty easy, and some are difficult -- but intrinsically difficult, not difficult due to some quirk of gdb. Another reason we took another look at gdb is the ongoing work by Code Sourcery on non-stop debugging and multi-process debugging. Some folks here are worried that gdb will not satisfy Red Hat's needs in the long term. Our plan to deal with this contingency is to re-examine our gdb work to see how we are doing -- either at the 6 month point, or if we hit a major architectural barrier. Our general plan is similar to what we discussed for frysk, though of course with some changes: * We will work on our own branch, with frequent merges from main line. We do intend to merge things back to the trunk, but having a branch will let us time that effort more easily. Also we want to have a somewhat different patch review approach, so that all team members are involved in patch review. (If you're curious, we'll most likely use a git repository for this branch.) * We'll set up our own mailing list(s) for discussion and patch review. I don't mind reusing the frysk list, but YMMV... please discuss. If you don't want the frysk list, feel free to suggest a name for the project. * We'll continue to discuss our roadmap and milestones in public. This will start in earnest once the mailing list situation is clear. * The C++ issue. We're still interested in having the debugger be implemented in C++. However, this will probably not be the first thing we tackle, primarily because we need various changes that will be occurring on gdb CVS trunk. * FWIW we're going to be looking into a couple other debugging-related projects. In particular, in addition to Alexandre Oliva's work on variable tracking in GCC, we will need a sub-project to change g++ to emit more debug info in some cases. Also, we'll need to work on making gdb work with froggy (maybe on an experimental branch). Naturally, anybody is welcome to join us in this effort. Tom