This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 4/n] OpenMP 4.0 offloading infrastructure: lto-wrapper
- From: Ilya Verbin <iverbin at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Cary Coutant <ccoutant at google dot com>, Richard Biener <rguenther at suse dot de>, Jan Hubicka <hubicka at ucw dot cz>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Thomas Schwinge <thomas at codesourcery dot com>, Kirill Yukhin <kirill dot yukhin at gmail dot com>, Andrey Turetskiy <andrey dot turetskiy at gmail dot com>
- Date: Tue, 14 Oct 2014 02:42:47 +0400
- Subject: Re: [PATCH 4/n] OpenMP 4.0 offloading infrastructure: lto-wrapper
- Authentication-results: sourceware.org; auth=none
- References: <20141002151457 dot GA59899 at msticlxl57 dot ims dot intel dot com> <20141008102650 dot GV1986 at tucnak dot redhat dot com> <20141009120738 dot GA7420 at msticlxl57 dot ims dot intel dot com> <20141009200703 dot GA56445 at GumBook dot local> <20141010065320 dot GA10376 at tucnak dot redhat dot com> <CAHACq4qgCNNxe+PPh3t8YVbdbbS5aUzeK=tH+Kp1r8Zxa1qG9Q at mail dot gmail dot com> <20141010170043 dot GQ10376 at tucnak dot redhat dot com>
On 10 Oct 19:00, Jakub Jelinek wrote:
> On Fri, Oct 10, 2014 at 09:51:02AM -0700, Cary Coutant wrote:
> > 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.
>
> For that I guess
> lhd_begin_section
> would need to replace:
> section = get_section (name, SECTION_DEBUG, NULL);
> with:
> section = get_section (name, SECTION_DEBUG | SECTION_EXCLUDE, NULL);
> either just for the .gnu.offload_lto prefixed section, or all.
> The question is what will old assemblers and/or linkers do with that, and
> if there are any that support linker plugins, but not SHF_EXCLUDE.
I've tried to set SECTION_EXCLUDE bit with as+ld version 2.20.51 and got a lot
of warnings like:
/tmp/ccg7P7iS.s:2: Warning: entity size for SHF_MERGE not specified
/tmp/ccg7P7iS.s:2: Warning: group name for SHF_GROUP not specified
as: /tmp/ccKFKXfc.o: warning: sh_link not set for section `.gnu.lto_main.11d9780ff2ebf166'
/usr/bin/ld: /tmp/ccKFKXfc.o: warning: sh_link not set for section `.gnu.lto_main.11d9780ff2ebf166'
I think, it can be placed under such ifdef:
#if defined (HAVE_SECTION_EXCLUDE) && HAVE_SECTION_EXCLUDE == 1
section = get_section (name, SECTION_DEBUG | SECTION_EXCLUDE, NULL);
#else
section = get_section (name, SECTION_DEBUG, NULL);
#endif
Currently there is HAVE_GAS_SECTION_EXCLUDE implemented in gcc/configure.ac, and
HAVE_SECTION_EXCLUDE can use it + check a version of the linker.
As for old assemblers and/or linkers, which doesn't support SHF_EXCLUDE:
On 10 Oct 08:53, Jakub Jelinek wrote:
> 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?
Yes, it's possible to determine the versions of gold and ld.bfd from the plugin
(plugin-api.h:ld_plugin_tag). But the problem is not only with plugins.
If linker plugin in disabled, collect2 runs lto-wrapper directly to compile
offload_lto sections and/or to perform usual LTO:
https://gcc.gnu.org/wiki/Offloading#Compilation_without_-flto_and_without_linker_plugin
And if -flto is absent, but offload_lto sections were emitted, the final binary
will contain them. Perhaps, collect2 could execute and parse `ld --version` to
determine whether it supports SHF_EXCLUDE.
Then, we need somehow pass this information from plugin or collect2 to
lto-wrapper.
Maybe using an option like --strip-offload-sections, but currently lto-wrapper
doesn't have its own options. And finally, under this option lto-wrapper will
execute `objcopy --remove-section=<offload_lto>` and return stripped objects
back to the linker or to collect2.
So, should I implement this stuff, or maybe just leave offload_lto sections in
the case of old binutils? :)
Thanks,
-- Ilya