[llvm-commits] [llvm] r154124 - /llvm/trunk/tools/lto/LTOCodeGenerator.cpp

[Rafael Espíndola]

> This looks like a bug: the linker should observe that bundle uses the symbol
> foo
> and that main provides the symbol foo, and pass "foo" to the internalize
> pass in
> the list of external symbols.  I think this is how the gold plugin does it.
> It's
> not a reason to turn off internalize altogether.  Hopefully Rafael can
> comment.

Sorry I got so much email lag.
This does look like a bug in the llvm/apple ld interface. With this
patch reverted and an extended test:

void foo(void) { }
__attribute__((visibility("hidden"))) void zed(void) { }
int main(int argc, char *argv[]) {
   foo();
   zed();
   return 0;
}

I can run

[espindola at desktop llvm]$ ./build/bin/clang -o main main.c  -O4
[espindola at desktop llvm]$ readelf  --dyn-syms main | grep foo
[espindola at desktop llvm]$ ./build/bin/clang -o main main.c  -O4
-Wl,-export-dynamic
[espindola at desktop llvm]$ readelf  --dyn-syms main | grep foo
     5: 00000000004006c0     1 FUNC    GLOBAL DEFAULT   13 foo

Note how in the first run we correctly internalize both foo and zed.
On the second one with -export-dynamic only zed is internalized
because it is hidden.

So the problem is not that internalized is run, it is that it is being
told that foo is not needed. (and I assume the -export-dynamic
behavior is the default on macho).

Can this patch be reverted and the problem fixed in ld? If not, we at
least need a way to enable this in the gold plugin, as we really want
it to run internalize there.

Cheers,
Rafael