From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 71D483842430; Tue, 28 Jul 2020 13:47:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 71D483842430 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1517E1E794; Tue, 28 Jul 2020 09:47:25 -0400 (EDT) Subject: Re: [PATCH] Unify Solaris procfs and largefile handling To: Rainer Orth , binutils@sourceware.org, gdb-patches@sourceware.org References: From: Simon Marchi Message-ID: <51f44a63-3062-39e5-14c5-ed08e32f2129@simark.ca> Date: Tue, 28 Jul 2020 09:47:19 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, 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:47:27 -0000 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? Simon