From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26740 invoked by alias); 17 Nov 2004 00:31:32 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26661 invoked from network); 17 Nov 2004 00:31:21 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 17 Nov 2004 00:31:21 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iAH0VBt6026940 for ; Tue, 16 Nov 2004 19:31:16 -0500 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iAH0VAr12147; Tue, 16 Nov 2004 19:31:10 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id F3243129D8C; Tue, 16 Nov 2004 19:30:57 -0500 (EST) Message-ID: <419A9BBE.6010000@gnu.org> Date: Wed, 17 Nov 2004 01:24:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Ian Lance Taylor Cc: gdb@sources.redhat.com Subject: Re: GDB is the GNU project's native debugger References: <419A2E2F.5010602@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00178.txt.bz2 > Andrew Cagney writes: > > >>GDB is the GNU project's native debuger. While we're certainly happy >>to accomodate people using GDB as either an embedded debugger or >>native debugger on other systems, the need to persue GDB as a native >>debugger on GNU systems must be our first priority. >> >>Do we all agree with this? > > > While I think we all agree with this in some sense, I think you should > spell out where you are going with this. > > For example, it would be easy to use this statement as the motivation > for removing features required for using gdb for embedded systems, or > on Windows. I don't think that would be appropriate. I think this first needs a little context. One group, the embedded companies have found that with very little effort (I believe the guesstimate is ~6 weeks) they can add an architecture to GDB, leveraging themselves a very powerful debugger. This work is typically contracted, and once the money dries up all incentive to further develop that code disappears. This creates a very on-sided relationship. The embedded targets get all the cool features of GDB while the native developers get to "support" (i.e., maintain) it. To address this (since you mention code removal) I've (lets face it is me willing to put my neck on the line and drive this forward) set clear technical criteria such as: > * END-OF-LIFE frame compatibility module > > GDB's internal frame infrastructure has been completely rewritten. > The new infrastructure making it possible to support key new features > .... or: - it has't built for a full release cycle - it has't worked for a full release cycle to identify code that can be removed. While this is helping, the fact that it is only by taking such action the code gets maintained tells us we should go further setting a clearer bar: for instance requiring test results against each major release; or clarifying that architectural changes to GDB's core allowing better support for native GNU systems take priority over concerns that it might break embedded code. > If you want to state that, where there is a direct and immediatete > conflict between the needs of GNU systems and the needs of other > systems, the needs of the GNU systems take priority, I could support > that. In addition, many people (including I) are now in a situtation where their financial future is in part dependant on their ability to work on GNU software. As such they are finding that this conflict directly affects their, or their peers, bottom line. A manouver that influences the timing of a decision to deprecate (new code can't use) or end-of-life (removing) a mechanism or accept/reject a change has the potential to either cost or save these embedded / contract engineering companies and their employees 10's if not 100's of thousands of dollars. (Having worked in both GNU native and enbedded contract engineering, I can confidently state that the embedded side is brutally cut throat and far more likely to attempt influence. This is also why when accepting a new architecture or system I've tried to set clear consistent acceptance criteria). > If you want to state that this applies to considerations of resources, > and of which parts of gdb to mark obsolescent, I could not support > that. I'm not sure what you mean. Andrew