[llvm-commits] [gold][patch] Add a pass-through option to the plugin

[Nick Lewycky]

Style cleanup:

+  for (std::vector<std::string>::iterator i =
options::pass_through.begin(),
+                                          e = options::pass_through.end();
+       i != e;
+       ++i) {

The i != e; and ++i can be on one line

+    std::string& item = *i;

Space before &, not after

+      if (add_input_library (item_p + 2) != LDPS_OK) {

Extra space after function name before paren.

+      if (add_input_file (item_p) != LDPS_OK) {

Extra space again!

Please fix those and commit.

This sure is a strange problem. The linker asks us what symbols the IR files
use, we tell it the wrong list (lacking symbols we will use) because we
can't produce the right one until after we have all the information about
all native symbols and all the IR files. The linker may have already
discarded a symbol as unused, only to have it come back to life after
add_input_file. Would it make sense to hard-code the plugin to tell gold to
search in libc and libgcc for any symbols that simplify-libcalls or the
backend may have added? That might not work so well for compiler-rt users.
Would it make sense to have gold iterate on the list of symbols? They
probably wouldn't like that at all, it would be the same as ignoring the
order of libraries and .o files on the command line. Maybe we could
conservatively include every libc/libgcc function our optimizers might add?
It'd be a pain to maintain.

Anyhow, I'm not going to ask you to pursue that (unless you really want to).
Your fix solves the problem without introducing a big mess for any of the
pieces.

Could anyone comment on what Apple's LTO link does about this?

Nick

On 18 June 2010 07:21, Rafael Espindola <espindola at google.com> wrote:

> The attached patch adds a pass-through option to the plugin. The use
> for this option is to ask the linker to take another look into some
> library or object. The case when one might want to do this is when
> codegen introduces a new undefined reference. The canonical example is
> libgcc.
>
> Cheers,
> --
> Rafael Ávila de Espíndola
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20100618/0a3f9eb1/attachment.html>