Cary Coutant <ccout...@google.com> writes: >> For each libcall, we need to decorate >> >> 1. Which library it comes from. It is OS/target dependent. >> 2. The dynamic and static library names. In most cases, they >> are the same. For glibc, they are different. > > Is there a relatively painless way to enumerate all the possible > libcalls? We could add a new plugin api and have the LTO plugin > register those symbols up front. The linker would make a note of where > each symbol is defined, and then automatically go back and add any > objects needed to resolve any references introduced by the > optimization pass.
This isn't quite what should happen, though. If the user does not specify -lm on the link line, then we should not add -lm, even if LTO somehow introduces a function that is defined in libm. Automatically adding -lm would introduce a surprising dynamic dependency in some cases. The user should be explicit about that. That is, it really doesn't matter which library libcalls come from. All we need to know is which libraries might satisfy new libcalls. This is what leads me in the direction of copying certain libraries mentioned on the command line to follow the LTO objects, much as -pass-through does. I think we just need to make that a little bit more automatic. Ian
