================
@@ -106,9 +111,14 @@ static void emitSCSEpilogue(MachineFunction &MF,
MachineBasicBlock &MBB,
CSI, [&](CalleeSavedInfo &CSR) { return CSR.getReg() == RAReg; }))
return;
+ const RISCVInstrInfo *TII = STI.getInstrInfo();
+ if (STI.hasFeature(RISCV::FeatureStdExtZicfiss)) {
----------------
samitolvanen wrote:
> Today, if you use software SCS on a platform without support they just fail,
> since the SCS won't be setup and gp(probably) points to invalid memory. Is it
> unreasonable to have it work the same in this case?
Sounds reasonable to me, but having a flag that allows one to explicitly select
between software and hardware shadow stacks is still a good idea IMO.
> WDYT about phrasing this an an opt-out flag, like `-force-software-scs`, and
> using a helper function, like :
For sanitizers, extra flags have typically been something like
`-fsanitize-[sanitizer]-[flag]`, e.g.
`-fsanitize-cfi-icall-generalize-pointers`:
https://clang.llvm.org/docs/ControlFlowIntegrity.html#indirect-function-call-checking
> It also occurs to me that X86 is getting/has backward edge CFI, right? how do
> we enable that in the x86 backend? How is GCC planning to spell these
> options, since I would suppose there needs to be some level of compatibility.
X86 uses the `-fcf-protection` flag for backward-edge at least, and AArch64
uses `-mbranch-protection` for both backward-edge (PAC) and forward-edge (BTI).
It would be great not to invent another command line option specifically for
RISC-V, so I quite like the idea of reusing the existing ShadowCallStack
front-end for hardware shadow stacks too.
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
