This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: VAX Ultrix? (Re: GDB dropping support for mips-irix and alpha-tru64)
- From: Pedro Alves <palves at redhat dot com>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>, brobecker at adacore dot com
- Cc: gdb at sourceware dot org
- Date: Wed, 15 Oct 2014 14:22:40 +0100
- Subject: Re: VAX Ultrix? (Re: GDB dropping support for mips-irix and alpha-tru64)
- Authentication-results: sourceware.org; auth=none
- References: <20140911185249 dot GA13931 at adacore dot com> <5439406D dot 6060107 at redhat dot com> <20141013133809 dot GB4805 at adacore dot com> <201410131603 dot s9DG3sAq002782 at glazunov dot sibelius dot xs4all dot nl>
On 10/13/2014 05:03 PM, Mark Kettenis wrote:
>> 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...
For my own education, which code are you referring to though?
The PT_READ_U / PT_WRITE_U bits in inf-ptrace.c?
>
> 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.
Yeah, I agree here.
Thanks,
Pedro Alves