================
@@ -591,7 +591,9 @@ obscure_indirect_call_arg_nocfg:
.globl safe_lr_at_function_entry_nocfg
.type safe_lr_at_function_entry_nocfg,@function
safe_lr_at_function_entry_nocfg:
-// CHECK-NOT: safe_lr_at_function_entry_nocfg
+// Due to state being reset after a label, paciasp is reported as
+// a signing oracle - this is a known false positive, ignore it.
+// CHECK-NOT: non-protected call{{.*}}safe_lr_at_function_entry_nocfg
cbz x0, 1f
ret // LR is safe at the start of the
function
1:
----------------
atrosinenko wrote:
I test gadget scanner on llvm-test-suite built at -O2 optimization level from
time to time. Surprisingly, there doesn't seem to be any issues reported for
functions without CFG information.
By the way, another issue came up when I was implementing #137224. I have no
statistics on real-world functions for which BOLT is unable to reconstruct the
CFG, but leaf functions are probably more widespread than shrink-wrap optimized
ones. For leaf functions without CFG, it turned out to be quite easy to improve
handling of the LR.
Considering false positives in general, IIRC there was something like 10 false
positives reported for llvm-test-suite by my prototype implementation. There
are still quite a number of false positives reported by top-of-the-patch-stack,
I plan upstreaming more patches to fix these.
https://github.com/llvm/llvm-project/pull/134146
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
