Depends on D29023, which is currently under review. In that change, I am adding diagnostic information to LLVM for why Stack Smash Protection has been applied to each function. This is the second stage, namely adding a new remark to clang, which is emitted when enabled via "-Rstack-protector".
Details
Diff Detail
Event Timeline
include/clang/Basic/DiagnosticFrontendKinds.td | ||
---|---|---|
229 | Can this "unknown reason" case actually happen? It seems like a bug that SSP insertion would not know why it's doing what it's doing. | |
229 | Rather than the potentially-opaque initialism SSP, could you say "stack protector" here? That would match the flag name better. | |
230 | Do we actually know that the cause is a call to alloca rather than a VLA? | |
232 | These two cases seem very easy to tell apart: if -fstack-protector-all is specified, use that diagnostic, otherwise the LLVM attribute must have been from a source-level attribute. | |
include/clang/Basic/DiagnosticGroups.td | ||
911 | The flags to control this are -fstack-protector*, so -Rstack-protector (or something starting -Rstack-protector) should be used here. |
Thanks for the comments. I have updated the diff accordingly, by removing the unknown case, adding a check to distinguish between the function attribute and command-line switch, and expanded the alloca remark to include VLAs. I also replaced the reference to SSP from the switch and remark text as suggested. To go with that, I changed the DiagGroup name.
Abandoning. Due to changes made in D29023, there is no more need for this patch. The new method followed in that patch means that clang gets support for the new remarks via -Rpass=stack-protector.
Can this "unknown reason" case actually happen? It seems like a bug that SSP insertion would not know why it's doing what it's doing.