[commit] Deprecate remaining STREQ uses
Andrew Cagney
cagney@gnu.org
Sun Dec 14 16:24:00 GMT 2003
> [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.
More information about the Gdb
mailing list