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 4F93B3857C52; Tue, 28 Jul 2020 13:03:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4F93B3857C52 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 3BBE4B2B3F; Tue, 28 Jul 2020 15:03:34 +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 nKA_EdrkMdRb; Tue, 28 Jul 2020 15:03:33 +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 9A58EB2761; Tue, 28 Jul 2020 15:03:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1595941413; bh=z2djKIv7hts5C4f57f69nyLqoyaFBNa/lUgMFf7ECjA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=d1O2EUN7hbVMdoMUa+gFQ+zG8llIx7Vqy/9Wm1OV1OQK0RtNrn2hF5xmEZ41ouY8m j2T2fG1kdxq5xCwiI1O4As7b+Pyb5OAesgaDJ3zLGOHIYWFfbzX/ojEL4jdL0P6CqV Eh16vy00gu7XWWBF/wqc0JR2sv29ySdFGWH/ODbPA0d1/YOyabqO6rjT6I1yjYGq4a 6GFNHPNse0O2LXjcXUv2O0IG6Stflgqj5JnJQvKXvewFeIlNNysjIQLoVa7b6YtOL1 4j8apGs54nECxDVmq4wkmfrywzb0QD5PPN66kMS8ay7Qt7aDxWWICPdjcRvMfuUnHd V39qyoTXn3WHw== From: Rainer Orth To: gdb-patches@sourceware.org Cc: binutils@sourceware.org Subject: Re: [PATCH] Unify Solaris procfs and largefile handling References: Date: Tue, 28 Jul 2020 15:03:27 +0200 In-Reply-To: (Rainer Orth's message of "Mon, 20 Jul 2020 13:28:19 +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.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:03:37 -0000 Rainer Orth writes: > Rainer Orth writes: > >> 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. > > 11 days gone since the last reminder... > > Could someone please review the gdb parts of this patch? As I'd > mentioned, the binutils side of things has already been approved, but > parts of config/largefile.m4 primarily affect gdb, so a second pair of > eyes there would be helpful. Another 8 days since the last reminder. This patch is necessary to unbreak the 32-bit Solaris builds. 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