Re: Update LTO plugin interface

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Dec 2, 2010 at 1:10 PM, Cary Coutant <ccoutant@google.com> wrote:
>> I propose that we add a new linker option: --plugin-callback. ?At each
>> point where this option appears on the command line, the linker will
>> call a new plugin callback entry point. ?The LTO plugin will replace the
>> all_symbols_read callback with this one. ?We will have the gcc driver
>> run the linker more or less like this:
>>
>> object-files -lc -lgcc --plugin-callback -lc -lgcc crtend.o crtn.o
>
> I'm not sure how this is any better than the pass-through option we're
> already using. That just has the plugin re-inject those libraries that
> you have placed after the --plugin-callback option. The crtend.o and
> crtn.o files could be handled by having the plugin claim them and
> re-inject them at the end.
>
> For every new routine that the gcc backend generates a new call to, it
> ought to know which library that routine is defined in, and should be
> able to add that library after the generated object(s) during the
> all-symbols-read callback. We really don't want to support arbitrary
> interposition at that point, because a user-supplied replacement might
> invalidate some assumptions that were made during optimization.
>

It sounds reasonable. We have to add those libraries very carefully.

For example, with "gcc -static" on Linux, the reference to glibc should
be passed to linker as "--start-group -lgcc -lgcc_eh -lc --end-group".


-- 
H.J.