From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16022 invoked by alias); 17 Nov 2004 19:48:53 -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 15964 invoked from network); 17 Nov 2004 19:48:43 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 17 Nov 2004 19:48:43 -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 iAHJmcGc032298 for ; Wed, 17 Nov 2004 14:48:38 -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 iAHJmZr10569; Wed, 17 Nov 2004 14:48:35 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1CE27129D8C; Wed, 17 Nov 2004 14:48:32 -0500 (EST) Message-ID: <419BAB0C.2000607@gnu.org> Date: Wed, 17 Nov 2004 22:59: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> <419A9BBE.6010000@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/msg00184.txt.bz2 Ian Lance Taylor wrote: > 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. It's a complex problem and as such has middle ground and negotiation dependant on the scale of the work: - Corinna recently changed an architecture interface and, since it was straight forward, did the 'busywork'. - The frame code, on the other hand, was anything but straight forward, it instead started with a single architecture and then expanded as back end maintainers did their (much appreciated) stuff. In the end though, a long list of architectures were simply deleted (should I have instead done the 'busywork' of frameifying the ns32k?). Perhaps you can expand on your point by explaining where you would strike up the balance for making an invasive change such as asynchronous native (proc, ptrace) support. GDB has many many non-async embedded targets, but only two natives. Should we predicate the work on the modification of all the embedded inferiors? Or should we accept that the work is so key to GDB's future as a native that we can tolerate a few short term problems? > 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. Red Hat, with it's GNU/Linux distributions (RHEL) uses a separate GDB rpm and not a combined source tree. I also suspect that the contract engineering group you refer to ("Cygnus") are now rarely doing a GDB import, and are tending towards the model you describe. If there were problems, I'm sure they would have been addressed. What I do see is continuing pressure and lobying, some times comming from the most ironic of quarters :-) Fortunatly, I also see a great deal of professionalism. Embedded companies taking on the standards, meeting, and exceeding them. Anyway, would it be useful if the process, as you describe it, was explicitly documented? > 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. Andrew