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. Richard. > >>> In fact, if the plugin claims all files, then as far as I can see your >>> new ld_plugin_input_file field is not required. And if the plugin does >>> not claim all files, I don't see how this can work. >> >> Stage 2 linker should: >> >> 1. Discard all previous inputs. > > How is this step done? > > >> My implementation is available on hjl/lto branch at > > Thanks, but I don't see any changes to gold there, so I don't see what > you have done to change the plugin interface. > > Ian >
