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 43111382E060; Tue, 28 Jul 2020 13:51:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 43111382E060 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 569B3B2D37; Tue, 28 Jul 2020 15:51:21 +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 7qfEio_r5GkP; Tue, 28 Jul 2020 15:51:21 +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 B9544B2D36; Tue, 28 Jul 2020 15:51:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1595944280; bh=FXicRaV6wCUyvAdrmwuHJ+sUPPc5hH8wltrLWWY2Fgw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=O3E54XTWTSpLesJZUEDZgiz30B3BQ43IDKl4+p6W0hANcXm8TO1K48VmLIHxBfUCL u38Qn4WDwiBnc2ZEu9hUql/7NHmZDF0ccd0zfHNx9MuOArNU5LAgzVaHB4NemVwEMi edq0LVntR/Tkw3tzJPw/co6FZ5gO1dTlYS+YkAxc7um5IQZR0IghnPlJWOLBOAU3/8 bZ3MYmxzCZ9Xr7hEI8pkkKNMHHYJ2Zhg3lo1Sj4wYnwOehKcUT3ZO9P2j1bhWRUdtD jtveRVNMAl2QPt6sNFvjCEhkTW1qMiX3rKRtFKmITIGYfQgDLMWIHxfkvok6iKoyJv RTrbIJ91diMlQ== From: Rainer Orth To: Simon Marchi Cc: binutils@sourceware.org, gdb-patches@sourceware.org Subject: Re: [PATCH] Unify Solaris procfs and largefile handling References: <51f44a63-3062-39e5-14c5-ed08e32f2129@simark.ca> Date: Tue, 28 Jul 2020 15:51:19 +0200 In-Reply-To: <51f44a63-3062-39e5-14c5-ed08e32f2129@simark.ca> (Simon Marchi's message of "Tue, 28 Jul 2020 09:47:19 -0400") 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.5 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: Tue, 28 Jul 2020 13:51:24 -0000 Hi Simon, > On 2020-06-30 11:15 a.m., Rainer Orth wrote: >> 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 > > I understood some (not all of this). > > Regarding the "old" and "new" procfs interfaces, can't you just always include > procfs.h and never sys/procfs.h? Using sys/procfs.h seems like it would only > be useful for pre-1997 Solaris, which doesn't seem useful. And then you could > have large file support always on? Unfortunately not: is sometimes used in code shared with non-Solaris systems, none of which have . So we'd have to conditionalize on HAVE_PROCFS_H vs. HAVE_SYS_PROCFS_H. And on older Solaris 11.3, even when using the new procfs interface, errors out when largefile support is enabled. As I said: it's a royal mess ;-( Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University