[PATCH] D91816: [Inline] prevent inlining on stack protector mismatch

Nick Desaulniers via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 20 12:59:43 PST 2020


nickdesaulniers added a comment.

In D91816#2407426 <https://reviews.llvm.org/D91816#2407426>, @void wrote:

> Are there tests to ensure that the appropriate stack protector level is added to the function after inlining?

This patch doesn't change the behavior when inlining occurs. (`adjustCallerSSPLevel` is what's called post successful inline, which adds the appropriate stack protection level)  This patch prevents inlining when the caller and callee do not match (when one does not have `ssp`, `sspstrong`, or `sspreq` fn attr), such that `adjustCallerSSPLevel` is not run on the caller.

So `adjustCallerSSPLevel` should already have existing code coverage for this behavior? Does it?  Digging through git history, it looks like you wrote `adjustCallerSSPLevel` in d154e283f28525a5fcfb063d4b527bb9a68a8608 in 2013.  It looks like you wrote llvm/test/Transforms/Inline/inline_ssp.ll which tests this behavior, which I've modified here.  So my changes to llvm/test/Transforms/Inline/inline_ssp.ll are probably what you're looking for.  Those should be carefully reviewed; basically, callers no longer get upgraded from "no ssp fn attrs" to their callers ssp fn attrs because inlining was blocked/prevented.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91816/new/

https://reviews.llvm.org/D91816



More information about the llvm-commits mailing list