[llvm-commits] [llvm] r154124 - /llvm/trunk/tools/lto/LTOCodeGenerator.cpp
Bill Wendling
wendling at apple.com
Fri Apr 6 13:45:39 PDT 2012
On Apr 6, 2012, at 12:34 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Bill,
>
>> The internalize pass can be dangerous for LTO.
>
> I'm kind of confused by your examples. In your first example
>
>> Consider the following program:
>>
>> $ cat main.c
>> void foo(void) { }
>>
>> int main(int argc, char *argv[]) {
>> foo();
>> return 0;
>> }
>> $ cat bundle.c
>> extern void foo(void);
>>
>> void bar(void) {
>> foo();
>> }
>> $ clang -o main main.c
>> $ clang -o bundle.so bundle.c -bundle -bundle_loader ./main
>> $ nm -m bundle.so
>> 0000000000000f40 (__TEXT,__text) external _bar
>> (undefined) external _foo (from executable)
>> (undefined) external dyld_stub_binder (from libSystem)
>> $ clang -o main main.c -O4
>
> (^ If this is running internalize then that's a bug. But it doesn't, right?)
>
No. It's only run during linking.
>> $ clang -o bundle.so bundle.c -bundle -bundle_loader ./main
>> Undefined symbols for architecture x86_64:
>> "_foo", referenced from:
>> _bar in bundle-elQN6d.o
>> ld: symbol(s) not found for architecture x86_64
>> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>
> 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.
>
The darwin linker uses export lists for these purposes. If the gold plugin automagically detects it, all the better.
>> The linker was told that the 'foo' in 'main' was 'internal' and had no uses, so
>> it was dead stripped.
>>
>> Another situation is something like:
>>
>> define void @foo() {
>> ret void
>> }
>>
>> define void @bar() {
>> call asm volatile "call _foo" ...
>> ret void
>> }
>>
>> The only use of 'foo' is inside of an inline ASM call. Since we don't look
>> inside those for uses of functions, we don't specify this as a "use."
>
> This is user error: the user should add a "used" attribute to foo. This isn't
> anything new: lots of people make this mistake (it's come up again and again on
> the mailing list and in bugzilla). The user should be educated here.
>
I've sent the user an email about this. :)
-bw
More information about the llvm-commits
mailing list