[PATCH] D19495: [sanitizers] read/write page fault detection on mac.

[Mike Aizatsky via llvm-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL267477: [sanitizers] read/write page fault detection on mac. (authored by aizatsky).

Changed prior to commit:
  http://reviews.llvm.org/D19495?vs=54906&id=54913#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D19495

Files:
  compiler-rt/trunk/lib/sanitizer_common/sanitizer_mac.cc
  compiler-rt/trunk/test/asan/TestCases/Linux/segv_read_write.c
  compiler-rt/trunk/test/asan/TestCases/Posix/segv_read_write.c

Index: compiler-rt/trunk/test/asan/TestCases/Posix/segv_read_write.c
===================================================================
--- compiler-rt/trunk/test/asan/TestCases/Posix/segv_read_write.c
+++ compiler-rt/trunk/test/asan/TestCases/Posix/segv_read_write.c
@@ -0,0 +1,26 @@
+// RUN: %clangxx_asan -std=c++11 -O0 %s -o %t
+// RUN: not %run %t       2>&1 | FileCheck %s --check-prefix=READ
+// RUN: not %run %t write 2>&1 | FileCheck %s --check-prefix=WRITE
+// UNSUPPORTED: powerpc64,mips
+
+#include <sys/mman.h>
+
+static volatile int sink;
+__attribute__((noinline)) void Read(int *ptr) { sink = *ptr; }
+__attribute__((noinline)) void Write(int *ptr) { *ptr = 0; }
+int main(int argc, char **argv) {
+  // Writes to shadow are detected as reads from shadow gap (because of how the
+  // shadow mapping works). This is kinda hard to fix. Test a random address in
+  // the application part of the address space.
+  void *volatile p =
+      mmap(nullptr, 4096, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+  munmap(p, 4096);
+  if (argc == 1)
+    Read((int *)p);
+  else
+    Write((int *)p);
+}
+// READ: AddressSanitizer: SEGV on unknown address
+// READ: The signal is caused by a READ memory access.
+// WRITE: AddressSanitizer: SEGV on unknown address
+// WRITE: The signal is caused by a WRITE memory access.
Index: compiler-rt/trunk/test/asan/TestCases/Linux/segv_read_write.c
===================================================================
--- compiler-rt/trunk/test/asan/TestCases/Linux/segv_read_write.c
+++ compiler-rt/trunk/test/asan/TestCases/Linux/segv_read_write.c
@@ -1,26 +0,0 @@
-// RUN: %clangxx_asan -std=c++11 -O0 %s -o %t
-// RUN: not %run %t       2>&1 | FileCheck %s --check-prefix=READ
-// RUN: not %run %t write 2>&1 | FileCheck %s --check-prefix=WRITE
-// UNSUPPORTED: powerpc64,mips
-
-#include <sys/mman.h>
-
-static volatile int sink;
-__attribute__((noinline)) void Read(int *ptr) { sink = *ptr; }
-__attribute__((noinline)) void Write(int *ptr) { *ptr = 0; }
-int main(int argc, char **argv) {
-  // Writes to shadow are detected as reads from shadow gap (because of how the
-  // shadow mapping works). This is kinda hard to fix. Test a random address in
-  // the application part of the address space.
-  void *volatile p =
-      mmap(nullptr, 4096, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
-  munmap(p, 4096);
-  if (argc == 1)
-    Read((int *)p);
-  else
-    Write((int *)p);
-}
-// READ: AddressSanitizer: SEGV on unknown address
-// READ: The signal is caused by a READ memory access.
-// WRITE: AddressSanitizer: SEGV on unknown address
-// WRITE: The signal is caused by a WRITE memory access.
Index: compiler-rt/trunk/lib/sanitizer_common/sanitizer_mac.cc
===================================================================
--- compiler-rt/trunk/lib/sanitizer_common/sanitizer_mac.cc
+++ compiler-rt/trunk/lib/sanitizer_common/sanitizer_mac.cc
@@ -500,7 +500,8 @@
 }
 
 SignalContext::WriteFlag SignalContext::GetWriteFlag(void *context) {
-  return UNKNOWN;  // FIXME: implement this.
+  ucontext_t *ucontext = static_cast<ucontext_t*>(context);
+  return ucontext->uc_mcontext->__es.__err & 2 /*T_PF_WRITE*/ ? WRITE : READ;
 }
 
 void GetPcSpBp(void *context, uptr *pc, uptr *sp, uptr *bp) {


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D19495.54913.patch
Type: text/x-patch
Size: 3267 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160425/ab37c9e9/attachment-0001.bin>