================
@@ -57,11 +57,14 @@ 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``
+(default option). ``-mforced-sw-shadow-stack`` make risc-v backend generate
+software shadow stack with `Zicfiss`_ when shadow stack enabled.
----------------
ilovepi wrote:

```suggestion
hardware shadow stack, which needs `Zicfiss`_. Note that with ``Zicfiss``_ the 
RISC-V backend will default to the hardware based shadow call stack. Users can 
force the RISC-V backend to generate the software shadow call stack with 
``Zicfiss``_ by passing ``-mforced-sw-shadow-stack``. 
```
Maybe this is easier to follow? Might also make sense to outline when 
`-mforced-sw-shadow-stack` is expected to work somewhere, e.g., it has no 
effect w/o `Zicfiss``.  TBH, in that case, the driver should probably issue an 
error, since its incompatible w/o the feature, but I'm not sure if we can do 
that check in the frontend or not.

https://github.com/llvm/llvm-project/pull/68075
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to