Summary:
This change comes from using lld for i686-windows-msvc. Before this change, lld
emits an error of:
error: relocation against symbol in discarded section: .xdata
It's possible that this could be addressed in lld, but I think this change is
reasonable on its own.
At a high level, this is being generated:
A (.text comdat) -> B (.text) -> C (.xdata comdat)
Where A is a C++ inline function, which references B, an exception handler
thunk, which references C, the exception handling info.
With this structure, lld will error when applying relocations to B if the C it
references has been discarded (some other C has been selected).
This change checks if A is comdat, and if so places the exception registration
thunk (B) in the comdata group of A (and B).
It appears that MSVC makes the __ehhandler function comdat.
Is it possible that duplicate thunks are being emitted into the final binary
with other linkers, or are they stripping the unused thunks?
Reviewers: rnk, majnemer, compnerd, smeenai
Reviewed By: rnk, compnerd
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38940
llvm-svn: 316219
Twine("__ehhandler$") + GlobalValue::dropLLVMManglingEscape(
ParentFunc->getName()),
TheModule);
+ if (auto *C = ParentFunc->getComdat())
+ Trampoline->setComdat(C);
BasicBlock *EntryBB = BasicBlock::Create(Context, "entry", Trampoline);
IRBuilder<> Builder(EntryBB);
Value *LSDA = emitEHLSDA(Builder, ParentFunc);
--- /dev/null
+; RUN: opt -mtriple=i686-unknown-windows-msvc -S -x86-winehstate < %s | FileCheck %s
+
+$f = comdat any
+
+define void @f() comdat personality i32 (...)* @__CxxFrameHandler3 {
+ invoke void @g() to label %return unwind label %unwind
+return:
+ ret void
+unwind:
+ %pad = cleanuppad within none []
+ cleanupret from %pad unwind to caller
+}
+
+declare void @g()
+declare i32 @__CxxFrameHandler3(...)
+
+; CHECK: define internal i32 @"__ehhandler$f"(i8*, i8*, i8*, i8*){{ .+}} comdat($f) {