From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id 0DEE83846411; Thu, 9 Jul 2020 10:50:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0DEE83846411 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=none smtp.mailfrom=ro@cebitec.uni-bielefeld.de Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id DAF7981D5B; Thu, 9 Jul 2020 12:50:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Wjkj7iVWTMc; Thu, 9 Jul 2020 12:50:43 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p4fddbb33.dip0.t-ipconnect.de [79.221.187.51]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id 2DC7182087; Thu, 9 Jul 2020 12:50:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1594291843; bh=x20Xpj/7jyxspaSa65MjzME2nY2unp+Imn9vn4jCL+0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=RrG++hKzapKLhh5KDAcnju0SL+qC2ovx4qL9LAsEiP8TBjkVXRl8YjBp5JYIS0bCb Iql43+2iDuahx9FEEIW7T8WqVb7w9U42stG1LIKTMGfOllYLwqAKewSZJ2vALmUyVT BJtrXd2WXgkN/SZYKJ+TITYD6wfm39VQan+jcvhMIlj4NKkOnDKjxmnJAX6Cp2QuDl NYI4C7rw/JGhNzXufWd8OXO1F3OBhJMfm9vsCaI9BYsAxatTdWSShoHZbrV8yIooIl qQKoulX/uL+YW5X8EhUwk4Tu4ugpSDclMXF2tttzB/SvEoqKeA4zZk8kQ9oDAgBp08 /kdZvsbtEkbNA== From: Rainer Orth To: gdb-patches@sourceware.org Cc: binutils@sourceware.org Subject: Re: [PATCH] Unify Solaris procfs and largefile handling References: Date: Thu, 09 Jul 2020 12:50:36 +0200 In-Reply-To: (Rainer Orth's message of "Tue, 30 Jun 2020 17:15:28 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3790.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 10:50:47 -0000 Could someone please review the GDB side of this patch? It's more than a week now. Nick already approved the binutils part, but it needs to go in as a whole. binutils 2.35 has branched already and I suspect he will be increasingly wary to allow it into the branch the closer the release date gets. Thanks. Rainer > GDB currently doesn't build on 32-bit Solaris: > > * On Solaris 11.4/x86: > > In file included from /usr/include/sys/procfs.h:26, > from /vol/src/gnu/gdb/hg/master/dist/gdb/i386-sol2-nat.c:24: > /usr/include/sys/old_procfs.h:31:2: error: #error "Cannot use procfs in the large file compilation environment" > #error "Cannot use procfs in the large file compilation environment" > ^~~~~ > > * On Solaris 11.3/x86 there are several more instances of this. > > The interaction between procfs and large-file support historically has > been a royal mess on Solaris: > > * There are two versions of the procfs interface: > > ** The old ioctl-based /proc, deprecated and not used any longer in > either gdb or binutils. > > ** The `new' (introduced in Solaris 2.6, 1997) structured /proc. > > * There are two headers one can possibly include: > > ** which only provides the structured /proc, definining > _STRUCTURED_PROC=1 and then including ... > > ** which defaults to _STRUCTURED_PROC=0, the ioctl-based > /proc, but provides structured /proc if _STRUCTURED_PROC == 1. > > * procfs and the large-file environment didn't go well together: > > ** Until Solaris 11.3, would always #error in 32-bit > compilations when the large-file environment was active > (_FILE_OFFSET_BITS == 64). > > ** In both Solaris 11.4 and Illumos, this restriction was lifted for > structured /proc. > > So one has to be careful always to define _STRUCTURED_PROC=1 when > testing for or using on Solaris. As the errors above > show, this isn't always the case in binutils-gdb right now. > > Also one may need to disable large-file support for 32-bit compilations > on Solaris. config/largefile.m4 meant to do this by wrapping the > AC_SYS_LARGEFILE autoconf macro with appropriate checks, yielding > ACX_LARGEFILE. Unfortunately the macro doesn't always succeed because > it neglects the _STRUCTURED_PROC part. > > To make things even worse, since GCC 9 g++ predefines > _FILE_OFFSET_BITS=64 on Solaris. So even if largefile.m4 deciced not to > enable large-file support, this has no effect, breaking the gdb build. > > This patch addresses all this as follows: > > * All tests for the header are made with > _STRUCTURED_PROC=1, the definition going into the various config.h > files instead of having to make them (and sometimes failing) in the > affected sources. > > * To cope with the g++ predefine of _FILE_OFFSET_BITS=64, > -U_FILE_OFFSET_BITS is added to various *_CPPFLAGS variables. It had > been far easier to have just > > #undef _FILE_OFFSET_BITS > > in config.h, but unfortunately such a construct in config.in is > commented by config.status irrespective of indentation and whitespace > if large-file support is disabled. I found no way around this and > putting the #undef in several global headers for bfd, binutils, ld, > and gdb seemed way more invasive. > > * Last, the applicability check in largefile.m4 was modified only to > disable largefile support if really needed. To do so, it checks if > compiles with _FILE_OFFSET_BITS=64 defined. If it > doesn't, the disabling only happens if gdb exists in-tree and isn't > disabled, otherwise (building binutils from a tarball), there's no > conflict. > > What initially confused me was the check for $plugins here, which > originally caused the disabling not to take place. Since AC_PLUGINGS > does enable plugin support if exists (which it does on > Solaris), the disabling never happened. > > I could find no explanation why the linker plugin needs large-file > support but thought it would be enough if gld and GCC's lto-plugin > agreed on the _FILE_OFFSET_BITS value. Unfortunately, that's not > enough: lto-plugin uses the simple-object interface from libiberty, > which includes off_t arguments. So to fully disable large-file > support would mean also disabling it in libiberty and its users: gcc > and libstdc++-v3. This seems highly undesirable, so I decided to > disable the linker plugin instead if large-file support won't work. > > The patch allows binutils+gdb to build on i386-pc-solaris2.11 (both > Solaris 11.3 and 11.4, using GCC 9.3.0 which is the worst case due to > predefined _FILE_OFFSET_BITS=64). Also regtested on > amd64-pc-solaris2.11 (again on Solaris 11.3 and 11.4), > x86_64-pc-linux-gnu and i686-pc-linux-gnu. > > Ok for master? While it would be nice to have this in the binutils 2.35 > and gdb 10 releases, I'd fully understand if the patch were considered > too risky so close to the branch dates. > > Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University