From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4867 invoked by alias); 17 Nov 2004 01:24:43 -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 4843 invoked from network); 17 Nov 2004 01:24:39 -0000 Received: from unknown (209.128.65.135) by sourceware.org with QMTP; 17 Nov 2004 01:24:39 -0000 Received: (qmail 26197 invoked by uid 10); 17 Nov 2004 01:24:39 -0000 Received: (qmail 4070 invoked by uid 500); 17 Nov 2004 01:24:30 -0000 From: Ian Lance Taylor To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: GDB is the GNU project's native debugger References: <419A2E2F.5010602@gnu.org> <419A9BBE.6010000@gnu.org> Date: Wed, 17 Nov 2004 01:53:00 -0000 In-Reply-To: <419A9BBE.6010000@gnu.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-11/txt/msg00179.txt.bz2 Andrew Cagney writes: > 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. I don't have a problem with removing specific target backends that are not supported. I don't agree with the length of time--I think it should be something like "a full release cycle or one year, whichever is longer." But I agree that in principle removing a specific non-functional backend is not problematic. > 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. The "clarification" in the last clause is not clear at all, and will vary a great deal in the eye of the beholder. One person's architectural change allowing better support is another person's arbitrary change requiring pointless busywork. Who is responsible for that busywork--the person making the change, or every single backend maintainer? These questions are not resolved by a general statement in favor of supporting GNU systems. > > 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). When you talk about "attempt influence" I can't help but feel that you are exporting internal Red Hat dissension to the external world. I've done plenty of embedded contract work, and frankly for most people getting the backend support into gdb is not all that important. You just get one version of gdb working and stick with that for as long as you can--normally a few years. (This has been somewhat broken recently as some new versions of gcc require new versions of gdb, but that was not historically the case--and indeed many people in the embedded world still use -gstabs+ when they compile to sidestep these problems). I understand that within Red Hat things are different--Red Hat understandably tries to use a single source tree for both native and embedded work. My point is that in my experience, outside Cygnus/Red Hat, very few people's bottom line is affected by deprecating code or changing gdb internals. So I think your point is wrong. That's not to say that I am opposed to clear consistent acceptance criteria for new backends. Of course that is a good idea, and gcc (which I think is clearly successful and should generally be the model for this sort of development, as I've said before) has that as well. > > 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. I mean what I said in my second paragraph above, the one about the "clarification." In particular, it's very easy to apply a broad, generally accepted statement in ways which are not, in fact, generally accepted. Ian