================ @@ -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`` ---------------- ilovepi wrote:
> 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 :-) ) No, I think your comment is on point. w.r.t. the diagnostic, my thoughts were that it at least makes sense to point out the need for the developer to double check the flags. Maybe i'm being overly cautious, though. I think using the whole triple is a good approach for platforms like Android and Fuchsia, where we can enable/disable certain features based on the target OS/SDK version. I don' think we can generalize that to other systems, but if *some* systems can automagically do the right thing its better than nothing. 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
