From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 6C12D385843F for ; Mon, 8 Nov 2021 23:18:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6C12D385843F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x14.wildebeest.org [172.31.17.150]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id BCE61302FBA6; Tue, 9 Nov 2021 00:18:32 +0100 (CET) Received: by reform (Postfix, from userid 1000) id 1B9092E806BE; Tue, 9 Nov 2021 00:18:32 +0100 (CET) Date: Tue, 9 Nov 2021 00:18:31 +0100 From: Mark Wielaard To: "Dmitry V. Levin" Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH v2] Improve building with LTO Message-ID: 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: <20211108100228.GC27916@altlinux.org> X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Mon, 08 Nov 2021 23:18:36 -0000 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)? 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. > > 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. Cheers, Mark