From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2818 invoked by alias); 14 Dec 2003 16:24:36 -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 2805 invoked from network); 14 Dec 2003 16:24:15 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 14 Dec 2003 16:24:15 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 503282B8F; Sun, 14 Dec 2003 11:23:57 -0500 (EST) Message-ID: <3FDC8E9D.4050807@gnu.org> Date: Sun, 14 Dec 2003 16:24:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: Kevin Buettner , Eli Zaretskii , drow@mvista.com, gdb@sources.redhat.com Subject: Re: [commit] Deprecate remaining STREQ uses References: <3FC119EB.1060102@gnu.org> <3FC234C0.1000500@gnu.org> <20031124165047.GA2227@nevyn.them.org> <1031124182547.ZM9776@localhost.localdomain> <3FC26407.9000704@gnu.org> <1031125000932.ZM11256@localhost.localdomain> <3FC60A75.8090803@gnu.org> <1031204044404.ZM3660@localhost.localdomain> <9743-Thu04Dec2003174358+0200-eliz@elta.co.il> <3FCF6FCA.30607@gnu.org> <1031212192642.ZM21819@localhost.localdomain> <3FDA64D0.7020306@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00202.txt.bz2 > [switched to gdb@] Kevin Buettner writes: >> > I suspect that what this boils down to is a difference in maintenance >> > philosophy: I would prefer to see old (deprecated) interfaces eliminated >> > as soon as possible even if it does involve touching possible candidates >> > for deletion, whereas you don't seem to mind having old interfaces >> > retained for longer periods of time. Cagney asks: >> To make this more concrete, perhaphs you could outline how this would >> have worked with the old vs new frame code. Jim Blandy replies: > Everyone posting so far has agreed that there are cases that are so > complex that deprecation is an appropriate strategy. Having tried to > incrementally update a port from the old to the new frame interfaces, > but instead having given up and just rewritten it from scratch, I > would say that many aspects of the frame interface are clearly on the > "deprecation is appropriate" side of the line. > > The issue at hand, STREQ, and the issue Kevin raised, complaints, are > cases that should have been on the other side of that line: just get > rid of the old uses immediately. Maybe not in the same commit, but > certainly before taking up other projects. If you look at the thread you'll notice that the task was clearly non-trivial. It required effort from both Kevin and I, it also identified and fixed bugs giving, in the end, an expected return on investment. Did it have to be done immediatly and up front, I'd argue that the vote is still out. Just remember that there is no simple straight line here, rather there is the squigly one drawn by those willing and able to do the real work that GDB requires. > But I think this principle does apply to the frame interfaces, just on > a different time scale: > > After GDB 6.0 was released, you floated some ideas about renovating > the target vector. While I like the direction these were going, I was > a little distressed to think that we were going to begin the process > of introducing a whole new class of deprecated target-related > interfaces before we had even finished removing uses of the deprecated > frame interfaces. Certainly, we shouldn't wait for backwater *-tdep.c > files that nobody can test, but we still have deprecated frame > machinery in actively maintained targets like the MIPS and the > PowerPC. > > I recognize that you and others have been working on these; I don't > mean to complain or be unappreciative. But I think we should get > those taken care of before plunging into deprecating interfaces from > an entirely new section of GDB. Jim, Kevin, relax. The new frame code was finished ~6 months ago (it took ~6 months although people have been talking about it for ~10 years). Since then, looking at the numbers, we find: alpha done arm done avr done cris d10v done frv done h8300 i386 done ia64 done m32r done m68hc11 done m68k done mcore mips mn10300 done ns32k pa powerpc s390 doneish sh 1/2 sparc doneish v850 vax x86-64 done xstormy16 With IBM most recently stepping forward to contributing the necessary s390 code (paperwork pending TM). Not bad, eh? For the PowerPC, given the number of parties with a significant financial interest (IBM, Apple, Red Hat, Motorola, Novel (aka SuSE) ...) and the presence of this feature on at least two OS road maps, I'm sure someone will soon step forward and help Kevin with the task. For the MIPS, while yes that is starting to show a few grey hairs, I've been quietly, efficiently and (well until now :) unassumingly, overhauling it (it stalled for a bit cos my main MIPS box died). As for the other architectures, there's clearly no immediate concern. This code is relatively well isolated so can live a while longer. Further, the longer interested parties delay the work, the less real work they may need to do. As you yourself observed, the occasional jumbo cleanup is often more efficient than constant incremental catchup. We are of course going to need to find some sort of exit clause though, but I see MichaelC is already working towards that. Having said all this, I can identify serious stagnation in areas where mechanisms have been deprecated. Most notable is our target support (and there we've still a plithera of embedded targets). Look at the count for the global deprecated_registers[] array which was declared bad how many years ago? mipsv4-nat.c:7 rs6000-tdep.c:8 core-sol2.c:10 irix5-nat.c:10 lynx-nat.c:12 remote-vx68.c:13 sun3-nat.c:14 remote-vxsparc.c:15 remote-vxmips.c:17 sparc-nat.c:32 If we're to more rapidly advance GDB, adding/finishing key feaures such as "async" (needed by MI), fast thread support (needs target and infrun changes), and even multi-process debugging, we must become more agressive in this area. That means cleaning up the relevant GNU/Linux targets, instigating changes target changes such as I proposed, and finally taking a good hard look at that long list at all those lingerking embedded targets. Andrew PS: For those that didn't know. Intel ships a GDB CLI compatible debugger on GNU/Linux. If anyone is looking for a reason to drive GDB's development harder, this is it.