================
@@ -238,6 +238,25 @@ void RISCVTargetInfo::getTargetDefines(const LangOptions
&Opts,
else
Builder.defineMacro("__riscv_32e");
}
+
+ if (Opts.CFProtectionBranch) {
+ auto Scheme = Opts.getCFBranchLabelScheme();
+ if (Scheme == CFBranchLabelSchemeKind::Default)
+ Scheme = getDefaultCFBranchLabelScheme();
+
+ Builder.defineMacro("__riscv_landing_pad");
+ switch (Scheme) {
+ case CFBranchLabelSchemeKind::Unlabeled:
+ Builder.defineMacro("__riscv_landing_pad_unlabeled");
+ break;
+ case CFBranchLabelSchemeKind::FuncSig:
+ Builder.defineMacro("__riscv_landing_pad_func_sig");
+ break;
----------------
mylai-mtk wrote:
To drop this case I have 2 options, but I think neither is appropriate.
+ Option 1:
```c++
case CFBranchLabelSchemeKind::FuncSig:
// TODO: Define macros after the func-sig scheme is implemented
break;
```
Considering we already accepted `-mcf-branch-label-scheme=func-sig`, if the
user uses the flag now, he would get a success program run, but incomplete
compilation result, which is also misleading, so it's better to add an error to
prevent the case, which leads to Option 2.
+ Option 2:
```c++
case CFBranchLabelSchemeKind::FuncSig:
// TODO: Define macros after the func-sig scheme is implemented
llvm::report_fatal_error("the func-sig scheme is not implemented yet!");
break;
```
This prevents the misleading results, but it breaks tests in the `main` trunk,
so existing tests for the func-sig scheme have to be removed, but I don't think
it's worth it to undo the work just to merge this PR.
---
Perhaps we should still pause this PR? This is not really an urgent thing given
the concern of misleading users.
https://github.com/llvm/llvm-project/pull/109600
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
