Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney <cagney at gnu dot org>]

> [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.