[clang] [llvm] [RISCV] Add Zicfiss support to the shadow call stack implementation. (PR #68075)

via cfe-commits cfe-commits at lists.llvm.org
Tue Jan 23 11:14:51 PST 2024


================
@@ -57,11 +57,16 @@ compiled application or the operating system. Integrating the runtime into
 the operating system should be preferred since otherwise all thread creation
 and destruction would need to be intercepted by the application.
 
-The instrumentation makes use of the platform register ``x18`` on AArch64 and
-``x3`` (``gp``) on RISC-V. For simplicity we will refer to this as the
-``SCSReg``. On some platforms, ``SCSReg`` is reserved, and on others, it is
-designated as a scratch register.  This generally means that any code that may
-run on the same thread as code compiled with ShadowCallStack must either target
+The instrumentation makes use of the platform register ``x18`` on AArch64,
+``x3`` (``gp``) on RISC-V with software shadow stack and ``ssp`` on RISC-V with
+hardware shadow stack, which needs `Zicfiss`_ and ``-mno-forced-sw-shadow-stack``
----------------
enh-google wrote:

> Related: what are our thoughts about a frontend warning/diagnostic when the mcpu supports the feature, but hasn't been selected?

isn't the problem there that it's unlikely to be a decision that's in the developer's hands? (because the real question is "does the OS support it?", and i think that's the counter-suggestion? "decide based on the whole triple", in effect, since taking Android as an example it's likely to be something like "if android && riscv64 && api level >= where you can assume hardware scs works".)

(apologies if this isn't what's really being talked about here --- i came in very late to a long conversation :-) )

https://github.com/llvm/llvm-project/pull/68075


More information about the cfe-commits mailing list