From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88792 invoked by alias); 19 Oct 2016 11:53:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 88777 invoked by uid 89); 19 Oct 2016 11:53:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*r:Sun, Bielefeld, bielefeld, Biotechnology X-HELO: smtp.CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE (HELO smtp.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Oct 2016 11:53:15 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id B7E6F987; Wed, 19 Oct 2016 13:53:12 +0200 (CEST) Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rv0m-gAouCmP; Wed, 19 Oct 2016 13:53:09 +0200 (CEST) Received: from lokon.CeBiTec.Uni-Bielefeld.DE (lokon.CeBiTec.Uni-Bielefeld.DE [129.70.161.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPS id 4D41B986; Wed, 19 Oct 2016 13:53:09 +0200 (CEST) Received: (from ro@localhost) by lokon.CeBiTec.Uni-Bielefeld.DE (8.15.2+Sun/8.15.2/Submit) id u9JBr8sj008925; Wed, 19 Oct 2016 13:53:08 +0200 (MEST) From: Rainer Orth To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: Fix gdb 7.12 C++ compilation on Solaris References: <5e1396ea-6599-6b9a-bc8b-f59defaf4c3a@redhat.com> Date: Wed, 19 Oct 2016 11:53:00 -0000 In-Reply-To: (Pedro Alves's message of "Tue, 18 Oct 2016 15:28:13 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2016-10/txt/msg00562.txt.bz2 Hi Pedro, >> Afterwards, I ran a 32-bit compilation, which (after adding >> --disable-largefile to avoid >> >> In file included from /usr/include/sys/procfs.h:28:0, >> from /vol/src/gnu/gdb/gdb/local/gdb/i386-sol2-nat.c:23: >> /usr/include/sys/old_procfs.h:39:2: error: #error "Cannot use procfs in the large file compilation environment" >> #error "Cannot use procfs in the large file compilation environment" >> ^ >> > > BTW, the gdb/procfs.c file is long overdue for an overall face > lift... All the !NEW_PROC_API code should be dead, AFAIK. Despite > the comments at the top, the file is no longer used for any > target other than Solaris: > > $ grep -rn "[^-]procfs\.o" gdb/config/ > gdb/config/sparc/sol2.mh:5: procfs.o proc-api.o proc-events.o proc-flags.o proc-why.o > gdb/config/i386/sol2-64.mh:3: procfs.o proc-api.o proc-events.o proc-flags.o proc-why.o > gdb/config/i386/i386sol2.mh:3: procfs.o proc-api.o proc-events.o proc-flags.o proc-why.o > > The other Unix ports mentioned are all gone. > > But I'm surprised that your Solaris build is including some > "old_procfs.h" though. I thought that any non-ancient Solaris > version would be going through NEW_PROC_API too. No wonder: i386-sol2-nat.c unconditionally includes , which has this: /* * This definition is temporary. Structured proc is the preferred API, * and the older ioctl-based interface will be removed in a future version * of Solaris. Until then, by default, including will * provide the older ioctl-based /proc definitions. To get the structured * /proc definitions, either include or define _STRUCTURED_PROC * to be 1 before including . */ #ifndef _STRUCTURED_PROC #define _STRUCTURED_PROC 0 #endif #if !defined(_KERNEL) && _STRUCTURED_PROC == 0 #include The Solaris code simply should include everywhere. > Doesn't this bit in gdb/configure.ac pick NEW_PROC_API for you > in 32-bit mode? : > > # Detect which type of /proc is in use, such as for Solaris. > > if test "${target}" = "${host}"; then > case "${host}" in > *-*-sysv4.2* | *-*-sysv5* ) > AC_DEFINE(NEW_PROC_API, 1, > [Define if you want to use new multi-fd /proc interface.]) > ;; > *-*-solaris2.[[6789]] | *-*-solaris2.1[[0-9]]*) > AC_DEFINE(NEW_PROC_API, 1, > [Define if you want to use new multi-fd /proc interface.]) > ;; > mips-sgi-irix5*) > # Work around needing _KMEMUSER problem on IRIX 5. > AC_DEFINE([_KMEMUSER], 1, > [Define to 1 so gets a definition of anon_hdl. Works > around a problem on IRIX 5.]) > ;; > esac > fi It did as it should. > It'd be great to find someone motivated to clean this all up. :-) > At least to make sure that the 32-bit and 64-bit compilations > take the same paths in the backend... Certainly: I initially encountered this in gcc when boehm-gc still used the ioctl-based procfs which is finally gone in Solaris 12: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01591.html Given that the structured one became available with Solaris 2.6 back in 1997, there's no need at all to deal with the old ioctl interface anywhere. Besides, given that GCC 4.9 was the last version to support Solaris 9, one might consider deprecating/removing anything before Solaris 10 in gdb, too. I'll see if I can find some spare cycles to clean procfs.c and friends up: there are tons of opportunities with anything but Solaris gone as clients of that file and a couple related ones. > FYI, AFAIK, no GDB maintainer cares for/tests on Solaris > routinely nowadays. Neither do I: just whenever a new gdb or binutils release arrives, I give them a try. I'm way behind even on Solaris/gcc maintenance, so I fear there's not much I can do about gdb on that front. However, there's a couple of Solaris patches for gdb 7.11 here: https://java.net/projects/solaris-userland/sources/gate/show/components/gdb/patches?rev=7127 Perhaps the authors can be motivated to contribute them upstream as they obviously intended ;-) >> Still ok for mainline? > > Still OK. Thanks. I'll commit as soon as I've sorted some problem with hg-git out: plain git is completely unusable for me. What about the 7.12 branch backport with the PR now filed? Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University