We've found an error during the use of LTO that appears to happen only
during the use of the gold linker.
We essentially have a file which is compiled *without* LTO:
f1() {
h1();
}
And a second file that is compiled/linked *with* LTO:
f2() {
f1();
h1();
}
This second file has the function h1() inlined during LTO.
The resulting executable fails because the symbol for h1 is weak in the
first .o and doesn't exist in the second .o.
All the actual code is below for reproducing the error.
Is this an error in the linker itself or in how LLVM deals with the symbols?
Daniel
cat > weakCpp.h << \!
class C {
public:
int simple_method() {return 1;}
int caller_method() ;
};
!
cat > weakImpl.cpp << \!
#include "weakCpp.h"
int C::caller_method() {
return simple_method();
}
!
cat > weakMain.cpp << \!
#include "weakCpp.h"
int call_methods_main() {
C instance;
return instance.simple_method() + instance.caller_method();
}
int main() {
return call_methods_main();
}
!
clang++ -O0 weakImpl.cpp -o weakImpl.o -c
clang++ -O1 -o weakMainO1.exe -flto -mcpu=cortex-a15 -mllvm
-debug-only=inline -static weakMain.cpp weakImpl.o -v
-Wl,-plugin-opt=-debug-only=inline -Wl,-fuse-ld=gold
-Wl,-plugin-opt=also-emit-llvm -Wl,-plugin-opt=obj-path=. >& O1.log
Daniel
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140530/96469afa/attachment.html>
> clang++ -O1 -o weakMainO1.exe -flto -mcpu=cortex-a15 -mllvm > -debug-only=inline -static weakMain.cpp weakImpl.o -v > -Wl,-plugin-opt=-debug-only=inline -Wl,-fuse-ld=gold > -Wl,-plugin-opt=also-emit-llvm -Wl,-plugin-opt=obj-path=. >& O1.logThose command line options don't exist on trunk. The following works for me: $ clang++ -O0 weakImpl.cpp -o weakImpl.o -c $ clang++ -O1 -o weakMainO1.exe -flto -static weakMain.cpp weakImpl.o Do you also see the issue with x86_64? Cheers, Rafael
So you see the issue as well in ARM? When doing a
objdump -D weakMainO1.exe | grep -A 10
"<_ZN1C13caller_methodEv>:"
I see:
00008b88 <_ZN1C13caller_methodEv>:
8b88: e92d4800 push {fp, lr}
8b8c: e1a0b00d mov fp, sp
8b90: e24dd008 sub sp, sp, #8
8b94: e58d0004 str r0, [sp, #4]
8b98: e59d0004 ldr r0, [sp, #4]
8b9c: ebffdd17 bl 0 <__preinit_array_end>
8ba0: e1a0d00b mov sp, fp
8ba4: e8bd4800 pop {fp, lr}
8ba8: e12fff1e bx lr
where the bl 0 causes a seg fault.
I'll check x86_64, but currently don't have that setup, so it'll
take me a little bit of time to check.
-----Original Message-----
From: Rafael Espíndola [mailto:rafael.espindola at gmail.com]
Sent: Friday, May 30, 2014 2:05 PM
To: Daniel Stewart
Cc: LLVM Developers Mailing List
Subject: Re: Error with Gold Linker during LTO
> clang++ -O1 -o weakMainO1.exe -flto -mcpu=cortex-a15 -mllvm
> -debug-only=inline -static weakMain.cpp weakImpl.o -v
> -Wl,-plugin-opt=-debug-only=inline -Wl,-fuse-ld=gold
> -Wl,-plugin-opt=also-emit-llvm -Wl,-plugin-opt=obj-path=. >& O1.log
Those command line options don't exist on trunk.
The following works for me:
$ clang++ -O0 weakImpl.cpp -o weakImpl.o -c
$ clang++ -O1 -o weakMainO1.exe -flto -static weakMain.cpp weakImpl.o
Do you also see the issue with x86_64?
Cheers,
Rafael
On Fri, May 30, 2014 at 9:01 AM, Daniel Stewart <stewartd at codeaurora.org> wrote:> > We’ve found an error during the use of LTO that appears to happen only > during the use of the gold linker. > > > > We essentially have a file which is compiled *without* LTO: > > f1() { > > h1(); > > } > > > > And a second file that is compiled/linked *with* LTO: > > f2() { > > f1(); > > h1(); > > } > > > > This second file has the function h1() inlined during LTO. > > > > The resulting executable fails because the symbol for h1 is weak in the > first .o and doesn’t exist in the second .o. > > > > All the actual code is below for reproducing the error. > > > > Is this an error in the linker itself or in how LLVM deals with the symbols?>From your description, it's an error in how LLVM generates thesymbols. It sounds like the linker sees an object that refers to h1 but does not see any objects that define h1. There is nothing the linker can do in such a case. Ian
> From your description, it's an error in how LLVM generates the > symbols. It sounds like the linker sees an object that refers to h1 > but does not see any objects that define h1. There is nothing the > linker can do in such a case.That is exactly right. It is http://llvm.org/bugs/show_bug.cgi?id=19901. Cheers, Rafael