This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [LTO merge][6/15][RFA] Driver
On Tue, 29 Sep 2009, Rafael Espindola wrote:
> >> + Â Â%{use-linker-plugin: \
> >> + Â Â-plugin %(linker_plugin_file) \
> >> + Â Â-plugin-opt=%(lto_wrapper) \
> >> + Â Â-plugin-opt=%(lto_gcc) \
> >> + Â Â%{static|static-libgcc:-plugin-opt=-libgcc=%(lto_libgcc)} Â Â Â Â\
> >
> > Why does the plugin need a special option for libgcc - but apparently not
> > for any of the other libraries distributed with GCC?
>
> Because the ME can create references to libgcc functions. Without this
> we would fail in this case:
>
> 1) Plugin reads the symbol table of the files that contain IL
> 2) There are no references to a particular function defined in libgcc
> (say libfoo)
> 3) The linker removes the file that defined libfoo since it was unused
> 4) The plugin does codegen and introduces a reference to libfoo
Thanks for the explanation. This may be a reasonable thing to do
initially, but it doesn't seem to be a full solution, as there are other
cases where symbol references could be introduced - built-in function
optimizations transforming a call to one function to a call to another
(likely in libc, which could be being linked statically), at least. Do
you have any way to eliminate that possibility? If not, perhaps handling
of .a libraries needs to handle more generally the possibility that the
set of referenced symbols could increase, and you should have a PR open
for replacing the libgcc-specific hack with something more general?
--
Joseph S. Myers
joseph@codesourcery.com