-
Notifications
You must be signed in to change notification settings - Fork 10.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[lld] Fix -ObjC load behavior with LTO #92162
Conversation
When -ObjC is passed, the linker must force load any object files that contain special sections that store Objective-C / Swift information that is used at runtime. This should work regadless if input files are bitcode or native, but it was not working with bitcode. This is because the sections that identify an object file that should be loaded were inconsistent when dealing with a native file vs bitcode file. In particular, bitcode files were not searched for `__TEXT,__swift` prefixed sections, while native files were. This means LLD wasn't loading certain bitcode files and forcing the user to introduce --force-load to their linker invocation for that archive.
d90efc5
to
24da8f1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for fixing this issue!
The related native code seems https://github.com/llvm/llvm-project/blob/main/lld/MachO/ObjC.cpp#L49.
@llvm/pr-subscribers-lld-macho @llvm/pr-subscribers-lld Author: Nuri Amari (NuriAmari) ChangesWhen -ObjC is passed, the linker must force load any object files that contain special sections that store Objective-C / Swift information that is used at runtime. This should work regadless if input files are bitcode or native, but it was not working with bitcode. This is because the sections that identify an object file that should be loaded were inconsistent when dealing with a native file vs bitcode file. In particular, bitcode files were not searched for This means LLD wasn't loading certain bitcode files and forcing the user to introduce --force-load to their linker invocation for that archive. Full diff: https://github.com/llvm/llvm-project/pull/92162.diff 2 Files Affected:
diff --git a/lld/test/MachO/objc.s b/lld/test/MachO/objc.s
index e7074141f0113..dbb9f1df27571 100644
--- a/lld/test/MachO/objc.s
+++ b/lld/test/MachO/objc.s
@@ -5,12 +5,14 @@
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/has-objc-category.s -o %t/has-objc-category.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/has-objc-symbol-and-category.s -o %t/has-objc-symbol-and-category.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/has-swift.s -o %t/has-swift.o
+# RUN: llvm-as %t/has-swift-ir-loaded.ll -o %t/has-swift-ir-loaded.o
+# RUN: llvm-as %t/has-swift-ir-not-loaded.ll -o %t/has-swift-ir-not-loaded.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/has-swift-proto.s -o %t/has-swift-proto.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/no-objc.s -o %t/no-objc.o
## Make sure we don't mis-parse a 32-bit file as 64-bit
# RUN: llvm-mc -filetype=obj -triple=armv7-apple-watchos %t/no-objc.s -o %t/wrong-arch.o
-# RUN: llvm-ar rcs %t/libHasSomeObjC.a %t/no-objc.o %t/has-objc-symbol.o %t/has-objc-category.o %t/has-swift.o %t/has-swift-proto.o %t/wrong-arch.o
-# RUN: llvm-ar rcs %t/libHasSomeObjC2.a %t/no-objc.o %t/has-objc-symbol-and-category.o %t/has-swift.o %t/has-swift-proto.o %t/wrong-arch.o
+# RUN: llvm-ar rcs %t/libHasSomeObjC.a %t/no-objc.o %t/has-objc-symbol.o %t/has-objc-category.o %t/has-swift.o %t/has-swift-proto.o %t/has-swift-ir-loaded.o %t/has-swift-ir-not-loaded.o %t/wrong-arch.o
+# RUN: llvm-ar rcs %t/libHasSomeObjC2.a %t/no-objc.o %t/has-objc-symbol-and-category.o %t/has-swift.o %t/has-swift-proto.o %t/has-swift-ir-loaded.o %t/has-swift-ir-not-loaded.o %t/wrong-arch.o
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %t/test.s -o %t/test.o
@@ -20,7 +22,7 @@
# RUN: %lld -lSystem %t/test.o -o %t/test -L%t -lHasSomeObjC2 -ObjC
# RUN: llvm-objdump --section-headers --syms %t/test | FileCheck %s --check-prefix=OBJC
-# RUN: %no-fatal-warnings-lld -lSystem %t/test.o -o %t/test --start-lib %t/no-objc.o %t/has-objc-symbol.o %t/has-objc-category.o %t/has-swift.o %t/has-swift-proto.o %t/wrong-arch.o --end-lib -ObjC 2>&1 \
+# RUN: %no-fatal-warnings-lld -lSystem %t/test.o -o %t/test --start-lib %t/no-objc.o %t/has-objc-symbol.o %t/has-objc-category.o %t/has-swift.o %t/has-swift-proto.o %t/has-swift-ir-loaded.o %t/has-swift-ir-not-loaded.o %t/wrong-arch.o --end-lib -ObjC 2>&1 \
# RUN: | FileCheck -check-prefix=WARNING %s
# RUN: llvm-objdump --section-headers --syms %t/test | FileCheck %s --check-prefix=OBJC
@@ -36,6 +38,7 @@
# OBJC-NEXT: 4 has_objc_symbol {{.*}} DATA
# OBJC-EMPTY:
# OBJC-NEXT: SYMBOL TABLE:
+# OBJC-DAG: g O __TEXT,__swift _foo
# OBJC-DAG: g F __TEXT,__text _main
# OBJC-DAG: g F __TEXT,__text _OBJC_CLASS_$_MyObject
# OBJC-DAG: g O __TEXT,__swift5_fieldmd $s7somelib4Blah_pMF
@@ -100,6 +103,20 @@ _has_dup:
.section __TEXT,__swift
.quad 0x1234
+#--- has-swift-ir-loaded.ll
+target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
+target triple = "x86_64-apple-darwin"
+
+@foo = global i64 1234, section "__TEXT,__swift"
+@llvm.used = appending global [1 x ptr] [ptr @foo]
+
+#--- has-swift-ir-not-loaded.ll
+target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
+target triple = "x86_64-apple-darwin"
+
+@bar = global i64 1234
+@llvm.used = appending global [1 x ptr] [ptr @bar]
+
#--- has-swift-proto.s
.section __TEXT,__swift5_fieldmd
.globl $s7somelib4Blah_pMF
diff --git a/llvm/lib/Bitcode/Reader/BitcodeReader.cpp b/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
index 19a15209f8b66..e64051cf53862 100644
--- a/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
+++ b/llvm/lib/Bitcode/Reader/BitcodeReader.cpp
@@ -306,7 +306,8 @@ static Expected<bool> hasObjCCategoryInModule(BitstreamCursor &Stream) {
return error("Invalid section name record");
// Check for the i386 and other (x86_64, ARM) conventions
if (S.find("__DATA,__objc_catlist") != std::string::npos ||
- S.find("__OBJC,__category") != std::string::npos)
+ S.find("__OBJC,__category") != std::string::npos ||
+ S.find("__TEXT,__swift") != std::string::npos)
return true;
break;
}
|
When -ObjC is passed, the linker must force load any object files that contain special sections that store Objective-C / Swift information that is used at runtime. This should work regadless if input files are bitcode or native, but it was not working with bitcode. This is because the sections that identify an object file that should be loaded were inconsistent when dealing with a native file vs bitcode file. In particular, bitcode files were not searched for `__TEXT,__swift` prefixed sections, while native files were. This means LLD wasn't loading certain bitcode files and forcing the user to introduce --force-load to their linker invocation for that archive. Co-authored-by: Nuri Amari <nuriamari@fb.com>
When -ObjC is passed, the linker must force load any object files that contain special sections that store Objective-C / Swift information that is used at runtime. This should work regadless if input files are bitcode or native, but it was not working with bitcode. This is because the sections that identify an object file that should be loaded were inconsistent when dealing with a native file vs bitcode file. In particular, bitcode files were not searched for `__TEXT,__swift` prefixed sections, while native files were. This means LLD wasn't loading certain bitcode files and forcing the user to introduce --force-load to their linker invocation for that archive. Co-authored-by: Nuri Amari <nuriamari@fb.com>
When -ObjC is passed, the linker must force load any object files that contain special sections that store Objective-C / Swift information that is used at runtime. This should work regadless if input files are bitcode or native, but it was not working with bitcode. This is because the sections that identify an object file that should be loaded were inconsistent when dealing with a native file vs bitcode file. In particular, bitcode files were not searched for `__TEXT,__swift` prefixed sections, while native files were. This means LLD wasn't loading certain bitcode files and forcing the user to introduce --force-load to their linker invocation for that archive. Co-authored-by: Nuri Amari <nuriamari@fb.com>
When -ObjC is passed, the linker must force load any object files that contain special sections that store Objective-C / Swift information that is used at runtime. This should work regadless if input files are bitcode or native, but it was not working with bitcode. This is because the sections that identify an object file that should be loaded were inconsistent when dealing with a native file vs bitcode file. In particular, bitcode files were not searched for `__TEXT,__swift` prefixed sections, while native files were. This means LLD wasn't loading certain bitcode files and forcing the user to introduce --force-load to their linker invocation for that archive. Co-authored-by: Nuri Amari <nuriamari@fb.com>
When -ObjC is passed, the linker must force load any object files that contain special sections that store Objective-C / Swift information that is used at runtime.
This should work regadless if input files are bitcode or native, but it was not working with bitcode. This is because the sections that identify an object file that should be loaded were inconsistent when dealing with a native file vs bitcode file. In particular, bitcode files were not searched for
__TEXT,__swift
prefixed sections, while native files were.This means LLD wasn't loading certain bitcode files and forcing the user to introduce --force-load to their linker invocation for that archive.