Re: Likely obsolete pieces of GDB

["Mark Kettenis" <mark.kettenis@xs4all.nl>]

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.