================
@@ -5736,6 +5736,17 @@ option.
     }];
 }
 
+def StackProtectorIgnoreDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+The ``stack_protector_ignore`` attribute skips analysis of the given local
+variable when determining if a function should use a stack protector.
+
+If ``-fstack-protector-all`` is specified then the given function will still
+use a stack protector, even if some/all variables have this attribute.
----------------
cooperp wrote:

Oh this is subtle yeah.  So there's both `-fstack-protector-all` and 
`-fstack-protector`. The behavior we have prior to this PR is:
- `-fstack-protector-all`: always add a stack protector to all functions, even 
if they don't contain AllocaInst or anything else
- `-fstack-protector`: only add stack protectors to functions which contain at 
least one AllocaInst over some size threshold (given by the 
`stack-protector-buffer-size` attribute)

What this PR is changing is the behavior for the latter case, ie, when it is 
scanning AllocaInst's and looking for those exceeding some size threshold. It 
opts specific AllocaInst's out of this analysis, but if others exist which are 
still large enough then we'll still get a stack protector.

Honestly not sure how best to document this.  I think the behavior is 
reasonable, even in terms of what you said about command line vs pragma vs 
attribute, but it does feel like we're getting in to the specifics of an LLVM 
backend pass and its logic.

https://github.com/llvm/llvm-project/pull/173311
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to