From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90375 invoked by alias); 15 May 2018 20:13:12 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 90352 invoked by uid 89); 15 May 2018 20:13:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_40,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=ROM, ram, RAM, H*f:sk:ef5578b X-HELO: smtpo75.poczta.onet.pl Received: from smtpo75.poczta.onet.pl (HELO smtpo75.poczta.onet.pl) (141.105.16.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 May 2018 20:13:10 +0000 Received: from INFERNUS (ac61.itcomp.pl [109.196.82.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: freddie_chopin@op.pl) by smtp.poczta.onet.pl (Onet) with ESMTPSA id 40lpdy47BBz1C6xjq for ; Tue, 15 May 2018 22:12:48 +0200 (CEST) Message-ID: <31a46b0c6c7c0b0af496d98b8697587bcf25338c.camel@op.pl> Subject: Re: LTO vs GCC 8 From: Freddie Chopin To: gcc@gcc.gnu.org Date: Tue, 15 May 2018 20:13:00 -0000 In-Reply-To: References: <7837e9b3a56c6eb8806ae42a0b2447d09b7e1078.camel@op.pl> <5AF5793A.1050900@westcontrol.com> <49DC31D9-92D9-48A1-935C-4B5B8A3BE47E@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00124.txt.bz2 On Tue, 2018-05-15 at 21:39 +0200, Freddie Chopin wrote: > On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote: > > As to a workaround for the ld bug you can try keeping all .debug_* > > sections. IIRC 2.30 has the bug fixed (on the branch). > > Indeed - "keeping" all the debug sections is a viable alternative. > I've > found out that it is enough to "keep" just these: > > /* DWARF 2 */ > .debug_info 0 : { KEEP(*(.debug_info .gnu.linkonce.wi.*)); } > ... > .debug_frame 0 : { KEEP(*(.debug_frame)); } > > I have to check whether debugging something like that is actually > possible (; Thanks for the workaround! Nope, sent it too fast... With these two (three) sections "kept" --gc- sections stops working and the executable I get is almost identical to the case when I have no --gc-sections at all: - lto + --gc-sections, sections "kept" - 133504 ROM + 4196 RAM - lto + --gc-sections, sections not "kept" (causes previously mentioned errors) - 120288 ROM + 3676 RAM - lto, sections not "kept" - 133812 ROM + 4220 RAM So it seems I have to patiently wait for new binutils if I would like to use LTO (; Regards, FCh