From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vmicros1.altlinux.org (vmicros1.altlinux.org [194.107.17.57]) by sourceware.org (Postfix) with ESMTP id 1C6F83858D39 for ; Tue, 9 Nov 2021 08:58:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1C6F83858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=altlinux.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=altlinux.org Received: from mua.local.altlinux.org (mua.local.altlinux.org [192.168.1.14]) by vmicros1.altlinux.org (Postfix) with ESMTP id 7E12972C8B8 for ; Tue, 9 Nov 2021 11:58:20 +0300 (MSK) Received: by mua.local.altlinux.org (Postfix, from userid 508) id 6E3557CFBAF; Tue, 9 Nov 2021 11:58:20 +0300 (MSK) Date: Tue, 9 Nov 2021 11:58:20 +0300 From: "Dmitry V. Levin" To: elfutils-devel@sourceware.org Subject: Re: [PATCH v2] Improve building with LTO Message-ID: <20211109085820.GA11255@altlinux.org> References: <20210214235718.7654b5f1.alex.miller@gmx.de> <20210218033856.18053044.alex.miller@gmx.de> <20210828093143.GA720@altlinux.org> <20211104112320.GA732@altlinux.org> <20211108100228.GC27916@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 08:58:22 -0000 Hi Mark, On Tue, Nov 09, 2021 at 12:18:31AM +0100, Mark Wielaard wrote: > Hi Dmitry, > > On Mon, Nov 08, 2021 at 01:02:28PM +0300, Dmitry V. Levin wrote: > > > Thanks. This patch was indeed one reason I kept postponing the release, > > > because I didn't have have time to properly review it. > > > > > > Which gcc versions have you tried this against (with/without -flto?) > > > > I tested with gcc10 and gcc11. > > I could try older versions, although I didn't feel that necessary. > > I also did try with gcc 4.8 and gcc 8 (both without lto though). > > > https://sourceware.org/bugzilla/show_bug.cgi?id=27367 will likely strike > > those who would build elfutils with -flto using gcc11+. > > But only if they use -ffat-lto-objects (which isn't the default)? Yes, but those who build elfutils with -flto are likely using -ffat-lto-objects if they build static libraries. > Did you see and try the patch I proposed? Do you think we should include > it? I would like someone else to check/try it. Yes, the patch makes run-readelf-self.sh test pass, and causes no visible regressions. I'm not familiar with that code to review the patch, but I'm happy to use it anyway. > > > does also impact symbol versioning for non-lto builds, so I am still a > > > little hesitant. I'll try to do some tests to make sure things look ok > > > with different gcc versions. > > > > What do you mean by "it does also impact symbol versioning for non-lto > > builds"? The code for non-lto builds changes, but the versioning > > should remain the same, shouldn't it? > > I meant I am paranoid :) We are using slightly different asm or an > attribute to mark the symbol version than we did before. But I double > checked the exported versioned symbols with and without this patch on > different gcc versions and they look fine. > > So I did just now push this patch. Thanks! -- ldv