From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27238 invoked by alias); 15 Oct 2014 13:22:50 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 27227 invoked by uid 89); 15 Oct 2014 13:22:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 15 Oct 2014 13:22:48 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FDMhON019188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 15 Oct 2014 09:22:43 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FDMfib017680; Wed, 15 Oct 2014 09:22:42 -0400 Message-ID: <543E7520.8060207@redhat.com> Date: Wed, 15 Oct 2014 13:22:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Mark Kettenis , brobecker@adacore.com CC: gdb@sourceware.org Subject: Re: VAX Ultrix? (Re: GDB dropping support for mips-irix and alpha-tru64) References: <20140911185249.GA13931@adacore.com> <5439406D.6060107@redhat.com> <20141013133809.GB4805@adacore.com> <201410131603.s9DG3sAq002782@glazunov.sibelius.xs4all.nl> In-Reply-To: <201410131603.s9DG3sAq002782@glazunov.sibelius.xs4all.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg00031.txt.bz2 On 10/13/2014 05:03 PM, Mark Kettenis wrote: >> Date: Mon, 13 Oct 2014 06:38:09 -0700 >> From: Joel Brobecker >> >>> 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