ychen added a comment. Thanks for taking a look!
In D132592#3749261 <https://reviews.llvm.org/D132592#3749261>, @aaron.ballman wrote: > Do we have any evidence that users need this level of control or will > understand how to properly use the attribute? The command line option makes > sense to me because it's an all-or-nothing flag, but I'm not certain I > understand the need for per-function control. https://github.com/llvm/llvm-project/blob/064a08cd955019da9130f1109bfa534e79b8ec7c/llvm/include/llvm/IR/Function.h#L639-L641, per-function unwind table entry depends on both nounwind and uwtable. We have nothrow attribute for nounwind but not nouwtable for uwtable. With this, a user could use function attributes to control unwind table entry generation which could only be achieved by inline assembly or writing assembly files directly. I'd consider this a companion of nothrow. So making them both per-function attribute seems natural? > Also, if a user gets this wrong (applies the attribute where they shouldn't), > what is the failure mode (does it introduce any exploitable behavior)? The flag may only suppress unwind table emission instead of causing more, the lack of unwind table may only stop control flow rather than giving it more freedom. So I think this is safe from a security perspective. Using it wrong may cause unnecessary crashes just like any other memory bugs, but not a malicious binary. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D132592/new/ https://reviews.llvm.org/D132592 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
