From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6897 invoked by alias); 29 Nov 2004 22:08:23 -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 4643 invoked from network); 29 Nov 2004 22:07:54 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 29 Nov 2004 22:07:54 -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 iATM7mNR011855 for ; Mon, 29 Nov 2004 17:07:53 -0500 Received: from localhost.redhat.com (vpn50-16.rdu.redhat.com [172.16.50.16]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iATM7mr27468; Mon, 29 Nov 2004 17:07:48 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 86FCA129D8C; Mon, 29 Nov 2004 17:07:02 -0500 (EST) Message-ID: <41AB9D83.90607@gnu.org> Date: Tue, 30 Nov 2004 16:26: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> <419BAB0C.2000607@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/msg00261.txt.bz2 >>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? My post has context. I've recently encountered situtations where developers were insisting that I test my changes on ULTRIX; or that I seek approval when making trivial and pre-announced changes. As such we all need a reality check. Remind ourselves what the overall objective here is; and against what baseline we should each measure our requests. > 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. I waited a year, and nothing happened. I think it is first important to recognize that the pressure placed on GDB is different to that encountered by other members of the toolchain - binutils and gcc. GCC, for instance, has a simple pipeline architecture: FRONTEND MIDDLEEND ... BACKEND. Individual FRONT, MIDDLE and BACK ends can largely be developed in isolation, and plugged in and out at will. Only when the is changed, as occurred when moving from RTL to SSA, to things get scary and slow careful engineering processes (as again applied to SSA) are required. Contrast that to GDB, where underlying the architecture is a relatively complex web of objects (there's an O-O model fighting to get out of the C code :-). When developing such a model a key process has to be refactoring the code - modifying the object model (changing relationships and interfaces) so that the next change can be accommodated - and a key attribute of refactoring is that each has a short cycle: taking days, and not years to complete. If we look over GDB's [short list of not so] recent core changes, we find that for the true inovations such as: - multi-arch started '98, not finished - frames started dec? '02, finished nov '04 - event-loop started '98, finished jun? '04 - regcache started dec? '02, not finished the innovator did (I pushed through 3/4 of the above) implement backward compatibility so that out-of-date systems were given an opportunity to update and consequently waited-a-year or more. When we examine how each of these changes panned out, though - the extra year makes no difference. Only when compatibility code starts to be removed (or I stand my ground and require an update as an predicate to another contributions) that we see activity to revive out of out-of-date systems (and then only for a limited set). You make the assertion: > A clean and elegant program is a goal, but it is not the only goal. We're not talking here about clean or elegant code. Rather we're discussing GDB's backlog of refactorings (struct value, struct location, struct symbol, ...); each made of many smaller changes; each establishing another part of a robust OO model; each dependant on earlier work; each ensuring a more maintainable code base; and most importantly each a prereq to adding advanced features to gdb. Such refactorings need to be performed in time periods that amount to weeks, and not the months or years we currently see. Is such a rate of change possible if we're required to constantly schedule flag days, or wait for a year? Andrew