Cary Coutant <ccout...@google.com> writes: >> 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.
I think it's a little bit better because it specifically handles the case of crtend.o and crtn.o. You're right, we could have the plugin know about those and claim them. But now the knowledge is in two places. But I don't feel very strongly about it as long as we can make it work. > 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. That is another good point. I still don't understand why in HJ's example a new not-previously-existing reference to -lm is introduced. Ian
