Re: Likely obsolete pieces of GDB

Mark Kettenis
2006-12-17T12:20:43Z

Daniel,

I mostly agree with your list, except for the following:

> Native and cross targets which might be obsolete:
>
> alpha*-*-osf*

Might be a bit too early for this. You can still buy new True64 systems
from HP. Support for alpha*-*-osf1 and alpha*-*-osf2 can probably be
dropped, but I think we want to keep alpha*-*-osf3.

If someone can send me some oldish Digital UNIX or True64 install cd's
for a version supported on the AlphaServer 800, I might have a go at
cleaning things up.

> hppa*-*-hiux*
>
> (Not hppa*-*-hpux*)

See my reply to Dave's message.

> i[34567]86-ncr-*
>
> i[34567]86-*-dgux*
>
> i[34567]86-*-lynxos*
>
> i[34567]86-*-netware*
>
> i[34567]86-*-sco3.2v5*
>
> i[34567]86-*-sco3.2v4*
>
> i[34567]86-*-sco*
>
> i[34567]86-*-sysv4.2*
>
> i[34567]86-*-sysv4*
>
> i[34567]86-*-sysv5*
>
> i[34567]86-*-unixware2*
>
> i[34567]86-*-unixware*
>
> i[34567]86-*-sysv*
>
> i[34567]86-*-isc*

Yes, it is time for these to go. The main reason they're still there is
because our current procedure for obsoleting targets is too complicated
and too ugly. I really can't get myself to put OBSOLETE on every line of
the affected source files. Can we change the policy to something like
what the GCC people do? They put a stanza in config.gcc that lists the
obsolete configs and bails out on those configs unless the user
specifies --enable-obsolete. Then the config gets removed completely
after the next release.

That said, I don't really have a problem with zapping these now.

> alpha-osf1-tdep.c
>
> Only used by the alpha-osf1 target. I'm pretty sure we don't
> need support for this platform anymore. But the last reference
> I see to it was from Joel in 2002; Joel, is this platform still
> relevant to you?

See my comments above.

> gnu-v2-abi.c
> gnu-v2-abi.h
>
> C++ ABI support for GCC 2.x.
>
> I'm not sure about these. The last release of GCC they worked
> with was 2.95.3. GCC 3.0 was released Jun 18, 2001. Adoption
> was slow, but I think I can safely say that almost no one uses
> 2.95.x any more; even Debian stopped using it three and a half
> years ago. Should we keep this?

Yes, we should keep this. Several OpenBSD platforms still use GCC 2.95.3.

> i386v-nat.c
>
> This file is used for i[34567]86-*-sco* and for
> i[34567]86-*-sysv4* and for i[34567]86-*-unixware* (but not
> unixware2*). I haven't heard of anyone using GDB on any of
> these configurations in a long time.
>
> Mark Kettenis was the last person to make a non-mechanical
> update to this file, in 2002. Mark, do you have any use for
> those targets?

Not really.

> infptrace.c
>
> I'd love to remove this old file (replaced by inf-ptrace.c)
> but I don't think we quite can yet. It appears to be still
> used by alpha-osf (probably obsolete), i386-sco and similar
> (also probably obsolete), but also powerpc-aix. AIX could
> use some updating if anyone wants to keep the GDB port to
> that platform alive.

Someone should really clean up the rs6000/powerpc mess, which really
is there because we hardly seem to have any people with access to AIX.

> mdebugread.c
> mdebugread.h
>
> If there's any platform left that still produces this format
> of symbolic debug information, I don't know what it is.

I think these are still necessary for Alpha (alpha-mdebug-tdep.c).

> solib-sunos.c
>
> Used by: config/arm/nbsdaout.mh config/i386/nbsdaout.mh
> config/i386/obsdaout.mh config/m68k/nbsdaout.mh
> config/m68k/obsd.mh config/sparc/nbsdaout.mh
> config/vax/nbsdaout.mh
>
> Are those a.out targets still current, and do they still use
> "SunOS" shared library support? If so we'll definitely
> keep this, but perhaps it needs a rename.

OpenBSD/m68k is still a.out and needs this for shared library support.

(OpenBSD/m88k and OpenBSD/vax are also still a.out, but they don't have
shared library support, and I guess they'll be switched to ELF before
they gain that support.)

The other configurations could be obsoleted I guess, although I'd like to
go the more formal route here, by listing them as obsolete, and removing
them after the next release.