On Wed, Dec 1, 2010 at 1:33 PM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Wed, Dec 1, 2010 at 10:28 PM, Ian Lance Taylor <i...@google.com> wrote: >> "H.J. Lu" <hjl.to...@gmail.com> writes: >> >>> On Wed, Dec 1, 2010 at 12:55 PM, Ian Lance Taylor <i...@google.com> wrote: >>>> "H.J. Lu" <hjl.to...@gmail.com> writes: >>>> >>>>> On Wed, Dec 1, 2010 at 12:37 PM, Ian Lance Taylor <i...@google.com> wrote: >>>>> >>>>>> Are you planning to have the plugin claim all files, even linker >>>>>> scripts, and then pass only the command line files back to the linker? >>>>>> >>>>> >>>>> Plugin will keep the same claim strategy. For those aren't claimed by >>>>> plugin, plugin will save and pass them back to linker only if they are >>>>> specified at command line. >>>> >>>> Just to be clear, that does not make sense as written. If the plugin >>>> does not claim a file, it should not then pass it back to the linker. >>> >>> API has >>> >>> typedef >>> enum ld_plugin_status >>> (*ld_plugin_claim_file_handler) ( >>> const struct ld_plugin_input_file *file, int *claimed); >>> >>> For linker script, archive, DSO and object file without IR, >>> *claimed will return 0 and plugin will save and pass it back to >>> linker later in if it is specified at command line. >> >> I don't understand what you wrote, so I am going to write what I think >> happens. >> >> The claim_file handler is an interface provided by the plugin itself. >> The plugin will register it via LDPT_REGISTER_CLAIM_FILE_HOOK. The >> linker proper will call it for each input file. >> >> In the case of the LTO plugin, this is the static function >> claim_file_handler in lto-plugin.c. >> >> If the plugin registers a claim_file handler, and, when the linker calls >> it, it returns with *claimed == 0, then the linker will process the file >> as it normally does. Since the file will already have been processed, >> it does not make sense for the plugin to then pass it back to the >> linker. The effect would be similar to listing the file twice on the >> command line. > > The basic problem is that if lto-plugin claims a file and provides a symtab > to the linker the link-time optimization might change that, including > adding new undefined symbols (think of libcalls). The linker needs > to re-process even not-claimed static archives (such as libgcc) to > resolve those new undefs. We hack around this by adding another > -lgcc at the end of the command-line, but that does change linker > resolution as the link order does matter. > > Basically we need to trigger a complete re-link with the claimed > object files substituted for the link-time optimized ones. >
That is what my implementation does. -- H.J.
