[PATCH] D25455: Document potential implementation of CFI in hardware.

[Peter Collingbourne via llvm-commits]

pcc added a comment.

My point was that this would make it more verbose to implement the bit vector check in software. But I think on balance this is fine because as you point out bit vector tests are relatively rare, I don't think we've removed as many as we can and even in the case where we want to be 100% we can always fall back to our existing code.



================
Comment at: docs/ControlFlowIntegrityDesign.rst:507
+A single new instruction added to an ISA would allow to perform the CFI check
+with fewer bytes per check (smaller code size overhead) and potentially more
+efficiently. Such instruction would check that the argument pointer is in-bounds,
----------------
An estimate of the # of bytes would be useful here.


================
Comment at: docs/ControlFlowIntegrityDesign.rst:509
+efficiently. Such instruction would check that the argument pointer is in-bounds,
+and is properly alignment, and if the checks fail it will either trap (in monolithic scheme)
+or call the slow path function (cross-DSO scheme).
----------------
aligned


================
Comment at: docs/ControlFlowIntegrityDesign.rst:523-526
+  // 'kAlignment' is a 4-bit constant.
+  // 'kRangeSize' is a ~20-bit constant.
+  // 'kRangeBeg' is a PC-relative constant (~28 bits)
+  //    pointing to the beginning of the allowed range for 'Ptr'.
----------------
Please put these in the same order as the "arguments" below.


https://reviews.llvm.org/D25455