[PATCH] D90426: hwasan: Support for outlined checks in the Linux kernel.
Mitch Phillips via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 29 17:36:08 PDT 2020
hctim added inline comments.
================
Comment at: llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h:40
+namespace HWASanAccessInfo {
+
----------------
why not `enum HWASanAccessInfo { ...`?
================
Comment at: llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp:396
+ if (HasMatchAllTag) {
+ OutStreamer->emitInstruction(MCInstBuilder(AArch64::UBFMXri)
+ .addReg(AArch64::X16)
----------------
IIUC, this is being optimised to
```
lsr x16, x1, #56
cmp x16, MatchAllTag
b.eq .ret
```
and this seems clearer to me. Is it possible to update the codegen here to be the same?
================
Comment at: llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp:513
+ OutStreamer->emitInstruction(
+ MCInstBuilder(AArch64::B).addExpr(HwasanTagMismatchRef), *STI);
+ } else {
----------------
`B` instead of `BR` implies that the kernel will never return from `__hwasan_tag_mismatch` (which is still reachable as it looks like it's still possible for the kernel to compile without short granules). Does this assumption always hold?
================
Comment at: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp:796
FunctionType::get(IRB.getVoidTy(), {PtrLong->getType()}, false),
- "int3\nnopl " + itostr(0x40 + AccessInfo) + "(%rax)",
+ "int3\nnopl " + itostr(0x40 + (AccessInfo & 0xffff)) + "(%rax)",
"{rdi}",
----------------
can we declare this as a const `kAccessInfoRuntimeMask` (and elsewhere)?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D90426/new/
https://reviews.llvm.org/D90426
More information about the llvm-commits
mailing list