[PATCH] D129016: [PowerPC] implemented @llvm.ppc.kill.canary to corrupt stack guard

ChenZheng via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jul 28 23:19:26 PDT 2022


shchenz added inline comments.


================
Comment at: clang/test/CodeGen/PowerPC/builtins-ppc-stackprotect.c:11
+// RUN:  FileCheck %s
+// RUN: %clang_cc1 -O2 -triple powerpc64-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | \
----------------
nit: do we need -O2?


================
Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:10702
+
+    // If SafeStack or !StackProtector, kill_canary is not supported.
+    if (MF.getFunction().hasFnAttribute(Attribute::SafeStack) ||
----------------
Is it possible to handle this when we generate `Intrinsic::ppc_kill_canary`, for example in the FE? Passing and handling this useless intrinsic in all the opt passes should be avoided?


================
Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:10718
+    // before corruption, so we XOR the canary word with all 1 bits.
+    const uint64_t XORWord = 0xFFFFFFFFFFFFFFFF;
+
----------------
nit: we may don't need this magic number here, we can use `DAG.getAllOnesConstant()` when we generate the `XOR` below?


================
Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:5
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux \
+; RUN:   --ppc-asm-full-reg-names < %s | FileCheck %s -check-prefix=LINUX
+
----------------
+1, we should add a RUN line for  64bit Linux LE for `-mtriple=powerpc64le-unknown-linux-gnu`

and for 32-bit AIX too.


================
Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:21
+
+attributes #0 = { sspreq }
+; Function Attrs: sspreq
----------------
nit: we may can add `nounwind` attribute to the function to remove the unnecessary `cfi` related instructions in the test.


================
Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:34
+; AIX-NEXT:    not r4, r4
+; AIX-NEXT:    std r4, 0(r3)
+; AIX-NEXT:    ld r3, 0(r3)
----------------
The functionality here seems wrong, AFAIK, we should overwrite the content in the slack slot instead of the data csect. Which means the store here should be `std r4, 120(r1)` instead of `std r4, 0(r3)`. Stack protection aims to check that the stack content is not changed unexpectedly.


================
Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:59
+; LINUX-NEXT:    not r3, r3
+; LINUX-NEXT:    std r3, 120(r1)
+; LINUX-NEXT:    ld r3, 120(r1)
----------------
Linux seems right...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129016/new/

https://reviews.llvm.org/D129016



More information about the cfe-commits mailing list