Re: VAX Ultrix? (Re: GDB dropping support for mips-irix and alpha-tru64)

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

> Date: Mon, 13 Oct 2014 06:38:09 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> > Going over the supported hosts in configure.host, I noticed we still
> > "support" VAX Ultrix / 4.2BSD:
> > 
> >  vax-*-bsd*)             gdb_host=vax ;;
> >  vax-*-ultrix*)          gdb_host=vax ;;
> > 
> > Does it make sense to keep support for old Ultrix given we're
> > dropping OSF/1 / Tru64?
> 
> Wikipedia says that VAX production ceased in 2005. The last VAX-specific
> patch I can see being submitted to gdb-patches is us mentioning support
> for VAX floats in the Ada mode (which we removed in 2010). VAX VMS was
> removed in 2010 from BFD. There seems to be some regular activity around
> VAX on the GCC side, though, but Ultrix itself seems to be no longer be
> supported.

There are probably quite a few VAXen still running.  Just learned last
week there are still some radiotelescopes around running a VAX to
control the telescope.  But they're probably running VMS on those
though.  If you want, there's the SIMH simulator.

> So this seems to indicate that we will be able to remove support
> for Ultrix.

FWIW, I kept the VAX Ultrix and VAX 4.2BSD code around as an example
of how a classic ptrace(2) implementation works.  Helped me a great
bit when refactoring inf-ptrace.c back in the days.  Linux really
turned ptrace(2) into a mess...

Other than the educational value, there is no point in keeping Ultrix
and BSD4.2 support alive.  I'm pretty sure that GDB has become too
bloated to compile and/or run on these systems.

> > Below's the table I was building, listing the full set of
> > supported hosts, according to configure.host, mapping OS to triplet.
> 
> > | HP-UX             | hppa*-*-hpux*                 |
> > | HP-UX             | ia64-*-hpux*                  |
> 
> I suspect that HP-UX will no longer find any takers. AdaCore had to
> step-up many many years go to keep those alive. The situation is
> different today, and we are stepping down.

It'd be somewhat sad to see inf-ttrace.c go.  IMHO ttrace(2) is by far
the best example of how to do a proper threads-aware debugger interface.