On Tue, Jan 19, 2016 at 10:36:28 +0100, Jakub Jelinek wrote:
> On Tue, Jan 19, 2016 at 09:57:01AM +0100, Richard Biener wrote:
> > On Mon, 18 Jan 2016, Ilya Verbin wrote:
> > > On Fri, Jan 15, 2016 at 09:15:01 +0100, Richard Biener wrote:
> > > > On Fri, 15 Jan 2016, Ilya Verbin wrote:
> > > > > II) The __offload_func_table, __offload_funcs_end,
> > > > > __offload_var_table,
> > > > > __offload_vars_end are now provided by the linker script, instead of
> > > > > crtoffload{begin,end}.o, this allows to surround all offload objects,
> > > > > even
> > > > > those that are not claimed by lto-plugin.
> > > > > Unfortunately it works only with ld, but doen't work with gold,
> > > > > because
> > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=15373
> > > > > Any thoughts how to enable this linker script for gold?
> > > >
> > > > The easiest way would probably to add this handling to the default
> > > > "linker script" in gold. I don't see an easy way around requiring
> > > > changes to gold here - maybe dumping the default linker script from
> > > > bfd and injecting the rules with some scripting so you have a complete
> > > > script. Though likely gold won't grok that result.
> > > >
> > > > Really a question for Ian though.
> > >
> > > Or the gcc driver can add crtoffload{begin,end}.o, but the problem is
> > > that it
> > > can't determine whether the program contains offloading or not. So it
> > > can add
> > > them to all -fopenmp/-fopenacc programs, if the compiler was configured
> > > with
> > > --enable-offload-targets=... The overhead would be about 340 bytes for
> > > binaries which doesn't use offloading. Is this acceptable? (Jakub?)
> >
> > Can lto-wrapper add them as plugin outputs? Or does that wreck ordering?
Currently it's implemented this way, but it will not work after my patch,
because e.g. offload-without-lto.o and offload-with-lto.o will be linked in
this order:
offload-without-lto.o, crtoffloadbegin.o, offload-with-lto.o, crtoffloadend.o
^^^^^^^^^^^^^^^^^^^^^
(will be not claimed by the plugin)
But we need this one:
crtoffloadbegin.o, offload-without-lto.o, offload-with-lto.o, crtoffloadend.o
> Yeah, if that would work, it would be certainly appreciated, one thing is
> wasting .text space and relocations in all -fopenmp programs (for -fopenacc
> programs one kind of assumes there will be some offloading in there),
> another one some extra constructor/destructor or what that would be even
> worse.
They contain only 5 symbols, without constructors/destructors.
-- Ilya
