From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6195 invoked by alias); 10 Oct 2014 16:51:07 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 6182 invoked by uid 89); 10 Oct 2014 16:51:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qc0-f176.google.com Received: from mail-qc0-f176.google.com (HELO mail-qc0-f176.google.com) (209.85.216.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 10 Oct 2014 16:51:05 +0000 Received: by mail-qc0-f176.google.com with SMTP id r5so2199605qcx.7 for ; Fri, 10 Oct 2014 09:51:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6hdrP0qkMIDogRGImTQnAqat650fzei6gK52Rxx0Fuc=; b=CcJ0+IKlQzfSp5llFmkDzPd1BEF2rhE59a9JufejsB1mVihzlPP4KHycTZmTXGh4Vf +5LmpVJP1kbqzfNFpQKzF9RXWfVpWqLIZqm42IVgobTwXQqU/2wRmynqRO01kiGFiG74 v5PSJ3i7jEydXo+JFhSglJZcD0Qg7W1GWJhZExNSpHpOIXI6cjXloOxI/cpGGwbEDV9p W9/axE7yX04hzMiEDjYpYw9s/GEeyA0AoJqDslhTVhZ6PHTq3aD4DqVEmD9hKM5k9+PS 38ExhnXh50vVeK+Nxw0iFrORauH638KCnPCs2hswU/8mMsye0hgV+YIJkrFqlj0h+mG+ QrLw== X-Gm-Message-State: ALoCoQlM+hTBUs8RoQ/FWyCGe9Z62BqwZzviof6ja5fuTMWq+DnKPwP0qw7SXq15vBzmnIXRIo8y MIME-Version: 1.0 X-Received: by 10.140.21.231 with SMTP id 94mr10046867qgl.90.1412959862520; Fri, 10 Oct 2014 09:51:02 -0700 (PDT) Received: by 10.140.81.51 with HTTP; Fri, 10 Oct 2014 09:51:02 -0700 (PDT) In-Reply-To: <20141010065320.GA10376@tucnak.redhat.com> References: <20141002151457.GA59899@msticlxl57.ims.intel.com> <20141008102650.GV1986@tucnak.redhat.com> <20141009120738.GA7420@msticlxl57.ims.intel.com> <20141009200703.GA56445@GumBook.local> <20141010065320.GA10376@tucnak.redhat.com> Date: Fri, 10 Oct 2014 16:52:00 -0000 Message-ID: Subject: Re: [PATCH 4/n] OpenMP 4.0 offloading infrastructure: lto-wrapper From: Cary Coutant To: Jakub Jelinek Cc: Ilya Verbin , Richard Biener , Jan Hubicka , gcc-patches , Thomas Schwinge , Kirill Yukhin , Andrey Turetskiy Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00978.txt.bz2 The linker already has a --strip-lto-sections option, and it's on by default. I'll approve a patch that modifies gold to recognize .gnu.offload_lto.* sections as part of --strip-lto-sections. Really, though, you should be setting the SHF_EXCLUDE bit on these sections. Do that and no special-casing will be necessary. Generating a linker script on the fly to discard these sections is, to me, rather hacky. There are better ways to do it. -cary On Thu, Oct 9, 2014 at 11:53 PM, Jakub Jelinek wrote: > On Fri, Oct 10, 2014 at 12:07:03AM +0400, Ilya Verbin wrote: >> On 09 Oct 16:07, Ilya Verbin wrote: >> > > > + /* By default linker does not discard .gnu.offload_lto_* sections. */ >> > > > + const char *linker_script = make_temp_file ("_linker_script.x"); >> > > > + FILE *stream = fopen (linker_script, "w"); >> > > > + if (!stream) >> > > > + fatal_error ("fopen %s: %m", linker_script); >> > > > + fprintf (stream, "SECTIONS { /DISCARD/ : { *(" >> > > > + OFFLOAD_SECTION_NAME_PREFIX "*) } }\n"); >> > > > + fclose (stream); >> > > > + printf ("%s\n", linker_script); >> > > > + >> > > > + goto finish; >> > > > + } >> > > >> > > Does this work with gold? Are there any other linkers that support plugins, >> > > but don't support linker scripts this way? >> > >> > Oops, gold does not support scripts, outputted from plugins :( >> > "error: SECTIONS seen after other input files; try -T/--script" >> > >> > Probably, we should update default linker scripts in binutils? >> > But without latest ld/gold all binaries compiled without -flto and with >> > offloading will contain intermediate bytecode... >> >> Actually, this issue is not due to outputting a script from a plugin, >> gold just does not support partial linker scripts: >> https://sourceware.org/bugzilla/show_bug.cgi?id=17451 >> >> So it seems that discarding .gnu.offload_lto_* sections (like it is done for >> .gnu.lto_*) in the default ld and gold scripts is the right way? > > I must say I'm not very much familiar with the linker plugin API, but it > surprises me that discarding sections is not something it allows. > Anyway, can you do the partial linker script for the bfd linker (is there > a way to determine from the linker plugin API if it is gold or bfd ld?), and > for gold for the time being perhaps strip the sections in lto-wrapper? and > feed the ET_REL objects with the sections stripped back to the linker > through the plugin API? > > Jakub