[PATCH] D31796: [cfi] Emit __cfi_check stub in the frontend

Peter Collingbourne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 6 18:01:06 PDT 2017


pcc added inline comments.


================
Comment at: lib/CodeGen/CGExpr.cpp:2790
+      llvm::FunctionType::get(VoidTy, {Int64Ty, Int8PtrTy, Int8PtrTy}, false),
+      llvm::GlobalValue::WeakAnyLinkage, "__cfi_check", &CGM.getModule());
+  llvm::BasicBlock *BB = llvm::BasicBlock::Create(Ctx, "entry", F);
----------------
eugenis wrote:
> pcc wrote:
> > eugenis wrote:
> > > pcc wrote:
> > > > Although this linkage may prevent inlining for now, we may in the future change the LTO implementation to promote weak functions to strong if the linker knows that a particular definition of a symbol is the final definition for the symbol. That will mean that this dummy definition may be inlined into callers.
> > > > 
> > > > This is a largely theoretical problem because we never create a direct call to the `__cfi_check` function. But if we wanted to fix this I can imagine creating an intrinsic that the CrossDSOCFI pass expands to the definition of `__cfi_check`.
> > > Do you mean  "expands to a call to __cfi_check"?
> > > We do need to have a definition of __cfi_check before CrossDSOCFI for the linker.
> > I mean basically that Clang would create a definition like this:
> > ```
> > define void @__cfi_check(i64 %0, i8* %1, i8* %2) {
> >   call void @llvm.cfi_check(i64 %0, i8* %1, i8* %2)
> >   ret void
> > }
> > ```
> > and CrossDSOCFI would find all calls to `@llvm.cfi_check` and replace them with the code that the pass currently generates as the body of `__cfi_check`.
> Ah, that definitely makes sense. Let's mention this in a comment for now.
Works for me.


Repository:
  rL LLVM

https://reviews.llvm.org/D31796





More information about the llvm-commits mailing list