chandlerc marked an inline comment as done. chandlerc added inline comments.
================ Comment at: llvm/docs/LangRef.rst:1659-1661 + that hardening. It should also be possible to *not* harden a hot and/or safe + function and have code inlined there *not* be hardened (even if the generic + form is hardened). ---------------- kristof.beyls wrote: > It feels wrong to me to have source code that is annotated to get hardened, > but that actually will not get hardened (whether it is due to it being > inlined somewhere or due to any other automatic > behind-the-back-of-the-developer transformation). I fear this may lower trust > in the protection this attribute provides. > I assume there is a use case where the developer wants to indicate "no > hardening in this function nor in any functions inlined here". If that needs > to be supported, my feel is that we may need to support that in another way. > I guess that there must be some cases where just duplicating the function to > be inlined in the source code into a hardened and a non-hardened version > could be too hard to do for some programs. > So, in short, I don't know what the best solution here is. I just want to > raise my concern that I don't think it's a good idea that functions that are > marked to be hardened end up not getting hardened under some circumstances. I actually started out with this, so I'm very sympathetic to the perspective. Given that you prefer it, let's start with this very conservative stance. We can always add specific mechanisms to be less conservative later, but I agree that it seems much better to start with a safe position. Repository: rL LLVM https://reviews.llvm.org/D51157 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
