https://github.com/ilovepi created
https://github.com/llvm/llvm-project/pull/92825
So long as ld -r links using bitcode always result in an ELF object, and
not a merged bitcode object, the output form a relocatable link using
FatLTO objects should not have a .llvm.lto section. Prior to this, usi
llvmbot wrote:
@llvm/pr-subscribers-lld-elf
Author: Paul Kirth (ilovepi)
Changes
So long as ld -r links using bitcode always result in an ELF object, and
not a merged bitcode object, the output form a relocatable link using
FatLTO objects should not have a .llvm.lto section. Prior to this,
MaskRay wrote:
There is a bitcode wrapper (see discussions at
https://reviews.llvm.org/D86847), but I agree that discarding `.llvm.lto` is
better since concatenated `.llvm.lto` does not reflect the `ld.lld -r
` semantics.
https://github.com/llvm/llvm-project/pull/92825
___
@@ -832,6 +832,15 @@ void ObjFile::initializeSections(bool ignoreComdats,
this->sections[i] =
createInputSection(i, sec, check(obj.getSectionName(sec, shstrtab)));
break;
+case SHT_LLVM_LTO:
+ // When doing a relocatable link with FatLTO objects,
@@ -832,6 +832,15 @@ void ObjFile::initializeSections(bool ignoreComdats,
this->sections[i] =
createInputSection(i, sec, check(obj.getSectionName(sec, shstrtab)));
break;
+case SHT_LLVM_LTO:
+ // When doing a relocatable link with FatLTO objects,
https://github.com/MaskRay edited
https://github.com/llvm/llvm-project/pull/92825
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
