From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9578 invoked by alias); 19 Nov 2004 03:13:44 -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 9565 invoked from network); 19 Nov 2004 03:13:40 -0000 Received: from unknown (209.128.65.135) by sourceware.org with QMTP; 19 Nov 2004 03:13:40 -0000 Received: (qmail 6337 invoked by uid 10); 19 Nov 2004 03:13:39 -0000 Received: (qmail 7825 invoked by uid 500); 18 Nov 2004 16:36:10 -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> <419BAB0C.2000607@gnu.org> Date: Fri, 19 Nov 2004 05:05:00 -0000 In-Reply-To: <419BAB0C.2000607@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/msg00194.txt.bz2 Andrew Cagney writes: > > 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? I think that in general you expanded on my point better than I could. As you say, it's a complex problem. You are proposing a simple principle, and my concern is that once such a thing is adopted it will be used to enforce simplistic solutions to complex problems. As I said before, the principle itself seems unobjectionable in many contexts. My concern is that it will be applied in cases where it is too simple. Or, to put it another way: why do we need an overly simple statement about what we agree is a complex issue? On your specific issue, I think that async native support would require either a flag day or supporting two separate interfaces for some time. A flag day is only acceptable if all major architectures can be converted simultaneously. Off the cuff I would say that supporting two separate interfaces would have to last for at least a year. Yes, this is hard. Yes, it leads to more duplicated work. A clean and elegant program is a goal, but it is not the only goal. > What I do see is continuing pressure and lobying, some times comming > from the most ironic of quarters :-) Well, you can make the lobbying public, or, since of course that may not be possible, you can ask for our input in an indirect fashion. I'm replying to the indirect query. Naturally I don't have all the information which you have. > Anyway, would it be useful if the process, as you describe it, was > explicitly documented? I'm not sure it makes much difference, myself. But on that question I may be too far on the inside, even though not a serious gdb developer. Perhaps for others with less historical knowledge, more documentation would be helpful. Ian