Win-Clang LTO build fails with LLD error: "LTO: late loaded symbol created new bitcode reference" |
|||
Issue descriptionSteps to reproduce: - Use Clang r283258 or later - Patch https://codereview.chromium.org/2390153003/ into Chromium - Run "gn args out\Release" with the following: (can probably skip the first one, need to update the llvm path) is_chrome_branded=true is_clang=true is_debug=false is_official_build=true target_cpu="x86" llvm_force_head_revision=true clang_use_chrome_plugins=false clang_base_path="d:\src\llvm\build.release64" use_lld=true - Try to build chrome_watcher.dll: ninja -C out\Release chrome_watcher.dll LLD fails with: "LTO: late loaded symbol created new bitcode reference" It seems two new files get added to BitcodeFiles during run(): base\field_trial.obj and base\build_time.obj . If I comment out the LLD code that errors, the build still seems to work fine. Rui: Do you have any ideas what's happening here?
,
Oct 4 2016
You might want to try passing in /verbose to lld as that should tell you which symbols caused those files to be added.
,
Oct 4 2016
Attaching the /verbose output. I can see a symbol from field_trial.obj and one from build_time.obj, but I can't really see how it relates to the LTO step.
,
Oct 10 2016
I think I see what's happening. The LTO step introduces a reference to __real@4330000000000000 . The linker has previously found a definition of that symbol in an object file in an archive, so it's a lazy symbol. Now that the new reference appears, the object file for the lazy symbol is parsed, and that object file references other lazy symbols, causing new bitcode files to be added *after* the LTO step. It's surprising that __real@4330000000000000 shows up as undefined in the combined LTO object though. I'd assume the compiler would emit a definition? Besides __real, there are also new references to __xmm@ffffffff ... and __aullrem . I guess the last one will be defined in some run-time library, but where are the others supposed to be defined?
,
Oct 10 2016
> It's surprising that __real@4330000000000000 shows up as undefined in the combined LTO object though. I'd assume the compiler would emit a definition? Oh, looking again at SymbolTable::addCombinedLTOObject() where the new __real@4330000000000000 reference shows up, it's not undefined in the object file, but we still go after the existing lazy symbol.
,
Oct 10 2016
Does this patch help?
diff --git a/lld/COFF/SymbolTable.cpp b/lld/COFF/SymbolTable.cpp
index df9da4c..58c3618a 100644
--- a/lld/COFF/SymbolTable.cpp
+++ b/lld/COFF/SymbolTable.cpp
@@ -347,11 +347,13 @@ void SymbolTable::addCombinedLTOObject(ObjectFile *Obj) {
Sym->Body = Body;
continue;
}
- if (auto *L = dyn_cast<Lazy>(Existing)) {
- // We may see new references to runtime library symbols such as __chkstk
- // here. These symbols must be wholly defined in non-bitcode files.
- addMemberFile(L);
- continue;
+ if (isa<Undefined>(Body)) {
+ if (auto *L = dyn_cast<Lazy>(Existing)) {
+ // We may see new references to runtime library symbols such as __chkstk
+ // here. These symbols must be wholly defined in non-bitcode files.
+ addMemberFile(L);
+ continue;
+ }
}
int Comp = Existing->compare(Body);
,
Oct 11 2016
Yes, that fixes it. Turning it into a patch here: https://reviews.llvm.org/D25461
,
Oct 12 2016
|
|||
►
Sign in to add a comment |
|||
Comment 1 by ruiu@google.com
, Oct 4 2016Summary: Win-Clang LTO build fails with LLD error: "LTO: late loaded symbol created new bitcode reference�" (was: Win-Clang LTO build fails with LLD error: "LTO: late loaded symbol created new bitcode reference ")