[PATCH] D133157: Add -fsanitizer-coverage=control-flow

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133157

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133157: Add -fsanitizer-coverage=control-flow

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added inline comments.



Comment at: 
compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_control_flow.cpp:24
+int main() {
+  int (*main_ptr)() = 
+  void (*foo_ptr)(int) = 

syntax nit:
  auto main_ptr = 



Comment at: 
compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_control_flow.cpp:33
+
+  printf("Control Flow section boundaries: [%p %p)\n", CFS_BEG, CFS_END);
+  uintptr_t *pt = CFS_BEG;

I suggest you move this to a separate function, called from main()



Comment at: 
compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_control_flow.cpp:67
+// CHECK: Control Flow section boundaries
+// CHECK: Saw the foo().
+// CHECK: Saw the main().

I don't think you are guaranteed to have main and foo in this order, and 
similarly dir vs indir call in this order. 
So, use CHECK-DAG instead of CHECK for these four lines. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133157

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133157: Add -fsanitizer-coverage=control-flow

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added inline comments.



Comment at: 
compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_control_flow.cpp:1
+// Tests -fsanitize-coverage=control-flow.
+

I suggest to make this test smaller:
* foo() can by empty (but avoid inlining)
* main() can have a single conditional call to foo

* main should also have a single conditional indirect call to test the -1 indir 
call marker. 

* __sanitizer_cov_cfs_init should capture its arguments and return

* main should insepct the arguments captured in __sanitizer_cov_cfs_init and 
verify that it sees main() and foo(), and that main contains calls to foo() and 
indir function, outside of the entry BB.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133157

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133157: Add -fsanitizer-coverage=control-flow

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added inline comments.



Comment at: clang/docs/SanitizerCoverage.rst:382
+  void __sanitizer_cov_cfs_init(const uintptr_t *cfs_beg,
+const uintptr_t *cfs_end) {
+// [cfs_beg,cfs_end) is the array of ptr-sized integers representing

vitalybuka wrote:
> vitalybuka wrote:
> > we can also generate normal structs, per function, and pass them into 
> > __sanitizer_cov_cfs_init(const MyStruct* begin, const MyStruct* end);
> > this was can avoid  this magic encoding completely?
> Works for me either way. @kcc WDYT? 
The struct will still have some variable length arrays, right?
Will it be any better?

MyStruct will have to be defined there, and there is no header file for sancov 
for users to include, and I don't think I want one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133157

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113447: [sancov] add tracing for loads and store

[Kostya Serebryany via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGb7f3a4f4fa14: [sancov] add tracing for loads and store 
(authored by kcc).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113447

Files:
  clang/docs/SanitizerCoverage.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/Driver/fsanitize-coverage.c
  
compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_trace_loads_stores.cpp
  llvm/include/llvm/Transforms/Instrumentation.h
  llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
  llvm/test/Instrumentation/SanitizerCoverage/trace-loads-stores.ll

Index: llvm/test/Instrumentation/SanitizerCoverage/trace-loads-stores.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/SanitizerCoverage/trace-loads-stores.ll
@@ -0,0 +1,33 @@
+; Test -sanitizer-coverage-inline-8bit-counters=1
+; RUN: opt < %s -passes='module(sancov-module)' -sanitizer-coverage-level=1 -sanitizer-coverage-trace-loads=1  -S | FileCheck %s --check-prefix=LOADS
+; RUN: opt < %s -passes='module(sancov-module)' -sanitizer-coverage-level=1 -sanitizer-coverage-trace-stores=1  -S | FileCheck %s --check-prefix=STORES
+
+target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
+target triple = "x86_64-unknown-linux-gnu"
+define void @foo(i8* %p1, i16* %p2, i32* %p4, i64* %p8, i128* %p16) {
+; === loads
+  %1 = load i8, i8* %p1
+  %2 = load i16, i16* %p2
+  %3 = load i32, i32* %p4
+  %4 = load i64, i64* %p8
+  %5 = load i128, i128* %p16
+; LOADS: call void @__sanitizer_cov_load1(i8* %p1)
+; LOADS: call void @__sanitizer_cov_load2(i16* %p2)
+; LOADS: call void @__sanitizer_cov_load4(i32* %p4)
+; LOADS: call void @__sanitizer_cov_load8(i64* %p8)
+; LOADS: call void @__sanitizer_cov_load16(i128* %p16)
+
+; === stores
+  store i8   %1, i8*   %p1
+  store i16  %2, i16*  %p2
+  store i32  %3, i32*  %p4
+  store i64  %4, i64*  %p8
+  store i128 %5, i128* %p16
+; STORES: call void @__sanitizer_cov_store1(i8* %p1)
+; STORES: call void @__sanitizer_cov_store2(i16* %p2)
+; STORES: call void @__sanitizer_cov_store4(i32* %p4)
+; STORES: call void @__sanitizer_cov_store8(i64* %p8)
+; STORES: call void @__sanitizer_cov_store16(i128* %p16)
+
+  ret void
+}
Index: llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
@@ -55,6 +55,16 @@
 const char SanCovTraceConstCmp2[] = "__sanitizer_cov_trace_const_cmp2";
 const char SanCovTraceConstCmp4[] = "__sanitizer_cov_trace_const_cmp4";
 const char SanCovTraceConstCmp8[] = "__sanitizer_cov_trace_const_cmp8";
+const char SanCovLoad1[] = "__sanitizer_cov_load1";
+const char SanCovLoad2[] = "__sanitizer_cov_load2";
+const char SanCovLoad4[] = "__sanitizer_cov_load4";
+const char SanCovLoad8[] = "__sanitizer_cov_load8";
+const char SanCovLoad16[] = "__sanitizer_cov_load16";
+const char SanCovStore1[] = "__sanitizer_cov_store1";
+const char SanCovStore2[] = "__sanitizer_cov_store2";
+const char SanCovStore4[] = "__sanitizer_cov_store4";
+const char SanCovStore8[] = "__sanitizer_cov_store8";
+const char SanCovStore16[] = "__sanitizer_cov_store16";
 const char SanCovTraceDiv4[] = "__sanitizer_cov_trace_div4";
 const char SanCovTraceDiv8[] = "__sanitizer_cov_trace_div8";
 const char SanCovTraceGep[] = "__sanitizer_cov_trace_gep";
@@ -122,6 +132,14 @@
   cl::desc("Tracing of DIV instructions"),
   cl::Hidden, cl::init(false));
 
+static cl::opt ClLoadTracing("sanitizer-coverage-trace-loads",
+   cl::desc("Tracing of load instructions"),
+   cl::Hidden, cl::init(false));
+
+static cl::opt ClStoreTracing("sanitizer-coverage-trace-stores",
+cl::desc("Tracing of store instructions"),
+cl::Hidden, cl::init(false));
+
 static cl::opt ClGEPTracing("sanitizer-coverage-trace-geps",
   cl::desc("Tracing of GEP instructions"),
   cl::Hidden, cl::init(false));
@@ -175,9 +193,11 @@
   Options.PCTable |= ClCreatePCTable;
   Options.NoPrune |= !ClPruneBlocks;
   Options.StackDepth |= ClStackDepth;
+  Options.TraceLoads |= ClLoadTracing;
+  Options.TraceStores |= ClStoreTracing;
   if (!Options.TracePCGuard && !Options.TracePC &&
   

[PATCH] D113447: [sancov] add tracing for loads and store

[Kostya Serebryany via Phabricator via cfe-commits]

kcc marked an inline comment as done.
kcc added inline comments.



Comment at: clang/test/Driver/autocomplete.c:73
 // FNOSANICOVERALL-NEXT: trace-pc-guard
+// FNOSANICOVERALL-NEXT: trace-loads
+// FNOSANICOVERALL-NEXT: trace-stores

morehouse wrote:
> This check is failing in the harbormaster build:  
> https://reviews.llvm.org/harbormaster/unit/view/1482705/
removed



Comment at: 
compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_trace_loads_stores.cpp:5
+//
+// RUN: %clangxx -O0 %s -fsanitize-coverage=func,trace-loads,trace-stores -o %t
+// RUN: %run %t 2>&1 | FileCheck %s

morehouse wrote:
> According to the documentation update in this patch, these flags don't work 
> without trace-pc or inline-8bit-counters.
Right. 
"func" is sort of synonym for trace-pc,func, but it's not worth the confusion 
in the test. 
changed to trace-pc


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113447

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113447: [sancov] add tracing for loads and store

[Kostya Serebryany via Phabricator via cfe-commits]

kcc updated this revision to Diff 385883.
kcc added a comment.

addressed review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113447

Files:
  clang/docs/SanitizerCoverage.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/Driver/fsanitize-coverage.c
  
compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_trace_loads_stores.cpp
  llvm/include/llvm/Transforms/Instrumentation.h
  llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
  llvm/test/Instrumentation/SanitizerCoverage/trace-loads-stores.ll

Index: llvm/test/Instrumentation/SanitizerCoverage/trace-loads-stores.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/SanitizerCoverage/trace-loads-stores.ll
@@ -0,0 +1,33 @@
+; Test -sanitizer-coverage-inline-8bit-counters=1
+; RUN: opt < %s -passes='module(sancov-module)' -sanitizer-coverage-level=1 -sanitizer-coverage-trace-loads=1  -S | FileCheck %s --check-prefix=LOADS
+; RUN: opt < %s -passes='module(sancov-module)' -sanitizer-coverage-level=1 -sanitizer-coverage-trace-stores=1  -S | FileCheck %s --check-prefix=STORES
+
+target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
+target triple = "x86_64-unknown-linux-gnu"
+define void @foo(i8* %p1, i16* %p2, i32* %p4, i64* %p8, i128* %p16) {
+; === loads
+  %1 = load i8, i8* %p1
+  %2 = load i16, i16* %p2
+  %3 = load i32, i32* %p4
+  %4 = load i64, i64* %p8
+  %5 = load i128, i128* %p16
+; LOADS: call void @__sanitizer_cov_load1(i8* %p1)
+; LOADS: call void @__sanitizer_cov_load2(i16* %p2)
+; LOADS: call void @__sanitizer_cov_load4(i32* %p4)
+; LOADS: call void @__sanitizer_cov_load8(i64* %p8)
+; LOADS: call void @__sanitizer_cov_load16(i128* %p16)
+
+; === stores
+  store i8   %1, i8*   %p1
+  store i16  %2, i16*  %p2
+  store i32  %3, i32*  %p4
+  store i64  %4, i64*  %p8
+  store i128 %5, i128* %p16
+; STORES: call void @__sanitizer_cov_store1(i8* %p1)
+; STORES: call void @__sanitizer_cov_store2(i16* %p2)
+; STORES: call void @__sanitizer_cov_store4(i32* %p4)
+; STORES: call void @__sanitizer_cov_store8(i64* %p8)
+; STORES: call void @__sanitizer_cov_store16(i128* %p16)
+
+  ret void
+}
Index: llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
@@ -55,6 +55,16 @@
 const char SanCovTraceConstCmp2[] = "__sanitizer_cov_trace_const_cmp2";
 const char SanCovTraceConstCmp4[] = "__sanitizer_cov_trace_const_cmp4";
 const char SanCovTraceConstCmp8[] = "__sanitizer_cov_trace_const_cmp8";
+const char SanCovLoad1[] = "__sanitizer_cov_load1";
+const char SanCovLoad2[] = "__sanitizer_cov_load2";
+const char SanCovLoad4[] = "__sanitizer_cov_load4";
+const char SanCovLoad8[] = "__sanitizer_cov_load8";
+const char SanCovLoad16[] = "__sanitizer_cov_load16";
+const char SanCovStore1[] = "__sanitizer_cov_store1";
+const char SanCovStore2[] = "__sanitizer_cov_store2";
+const char SanCovStore4[] = "__sanitizer_cov_store4";
+const char SanCovStore8[] = "__sanitizer_cov_store8";
+const char SanCovStore16[] = "__sanitizer_cov_store16";
 const char SanCovTraceDiv4[] = "__sanitizer_cov_trace_div4";
 const char SanCovTraceDiv8[] = "__sanitizer_cov_trace_div8";
 const char SanCovTraceGep[] = "__sanitizer_cov_trace_gep";
@@ -122,6 +132,14 @@
   cl::desc("Tracing of DIV instructions"),
   cl::Hidden, cl::init(false));
 
+static cl::opt ClLoadTracing("sanitizer-coverage-trace-loads",
+   cl::desc("Tracing of load instructions"),
+   cl::Hidden, cl::init(false));
+
+static cl::opt ClStoreTracing("sanitizer-coverage-trace-stores",
+cl::desc("Tracing of store instructions"),
+cl::Hidden, cl::init(false));
+
 static cl::opt ClGEPTracing("sanitizer-coverage-trace-geps",
   cl::desc("Tracing of GEP instructions"),
   cl::Hidden, cl::init(false));
@@ -175,9 +193,11 @@
   Options.PCTable |= ClCreatePCTable;
   Options.NoPrune |= !ClPruneBlocks;
   Options.StackDepth |= ClStackDepth;
+  Options.TraceLoads |= ClLoadTracing;
+  Options.TraceStores |= ClStoreTracing;
   if (!Options.TracePCGuard && !Options.TracePC &&
   !Options.Inline8bitCounters && !Options.StackDepth &&
-  !Options.InlineBoolFlag)
+  !Options.InlineBoolFlag && !Options.TraceLoads 

[PATCH] D113447: [sancov] add tracing for loads and store

[Kostya Serebryany via Phabricator via cfe-commits]

kcc created this revision.
kcc added a reviewer: morehouse.
Herald added subscribers: ormris, dexonsmith, dang, hiraditya.
kcc requested review of this revision.
Herald added projects: clang, Sanitizers, LLVM.
Herald added subscribers: llvm-commits, Sanitizers, cfe-commits.

add tracing for loads and stores.

The primary goal is to have more options for data-flow-guided fuzzing,
i.e. use data flow insights to perform better mutations or more agressive 
corpus expansion.
But the feature is general puspose, could be used for other things too.

Pipe the flag though clang and clang driver, same as for the other 
SanitizerCoverage flags.
While at it, change some plain arrays into std::array.

Tests: clang flags test, LLVM IR test, compiler-rt executable test.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D113447

Files:
  clang/docs/SanitizerCoverage.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/Driver/autocomplete.c
  clang/test/Driver/fsanitize-coverage.c
  
compiler-rt/test/sanitizer_common/TestCases/sanitizer_coverage_trace_loads_stores.cpp
  llvm/include/llvm/Transforms/Instrumentation.h
  llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
  llvm/test/Instrumentation/SanitizerCoverage/trace-loads-stores.ll

Index: llvm/test/Instrumentation/SanitizerCoverage/trace-loads-stores.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/SanitizerCoverage/trace-loads-stores.ll
@@ -0,0 +1,33 @@
+; Test -sanitizer-coverage-inline-8bit-counters=1
+; RUN: opt < %s -passes='module(sancov-module)' -sanitizer-coverage-level=1 -sanitizer-coverage-trace-loads=1  -S | FileCheck %s --check-prefix=LOADS
+; RUN: opt < %s -passes='module(sancov-module)' -sanitizer-coverage-level=1 -sanitizer-coverage-trace-stores=1  -S | FileCheck %s --check-prefix=STORES
+
+target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
+target triple = "x86_64-unknown-linux-gnu"
+define void @foo(i8* %p1, i16* %p2, i32* %p4, i64* %p8, i128* %p16) {
+; === loads
+  %1 = load i8, i8* %p1
+  %2 = load i16, i16* %p2
+  %3 = load i32, i32* %p4
+  %4 = load i64, i64* %p8
+  %5 = load i128, i128* %p16
+; LOADS: call void @__sanitizer_cov_load1(i8* %p1)
+; LOADS: call void @__sanitizer_cov_load2(i16* %p2)
+; LOADS: call void @__sanitizer_cov_load4(i32* %p4)
+; LOADS: call void @__sanitizer_cov_load8(i64* %p8)
+; LOADS: call void @__sanitizer_cov_load16(i128* %p16)
+
+; === stores
+  store i8   %1, i8*   %p1
+  store i16  %2, i16*  %p2
+  store i32  %3, i32*  %p4
+  store i64  %4, i64*  %p8
+  store i128 %5, i128* %p16
+; STORES: call void @__sanitizer_cov_store1(i8* %p1)
+; STORES: call void @__sanitizer_cov_store2(i16* %p2)
+; STORES: call void @__sanitizer_cov_store4(i32* %p4)
+; STORES: call void @__sanitizer_cov_store8(i64* %p8)
+; STORES: call void @__sanitizer_cov_store16(i128* %p16)
+
+  ret void
+}
Index: llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
@@ -55,6 +55,16 @@
 const char SanCovTraceConstCmp2[] = "__sanitizer_cov_trace_const_cmp2";
 const char SanCovTraceConstCmp4[] = "__sanitizer_cov_trace_const_cmp4";
 const char SanCovTraceConstCmp8[] = "__sanitizer_cov_trace_const_cmp8";
+const char SanCovLoad1[] = "__sanitizer_cov_load1";
+const char SanCovLoad2[] = "__sanitizer_cov_load2";
+const char SanCovLoad4[] = "__sanitizer_cov_load4";
+const char SanCovLoad8[] = "__sanitizer_cov_load8";
+const char SanCovLoad16[] = "__sanitizer_cov_load16";
+const char SanCovStore1[] = "__sanitizer_cov_store1";
+const char SanCovStore2[] = "__sanitizer_cov_store2";
+const char SanCovStore4[] = "__sanitizer_cov_store4";
+const char SanCovStore8[] = "__sanitizer_cov_store8";
+const char SanCovStore16[] = "__sanitizer_cov_store16";
 const char SanCovTraceDiv4[] = "__sanitizer_cov_trace_div4";
 const char SanCovTraceDiv8[] = "__sanitizer_cov_trace_div8";
 const char SanCovTraceGep[] = "__sanitizer_cov_trace_gep";
@@ -122,6 +132,14 @@
   cl::desc("Tracing of DIV instructions"),
   cl::Hidden, cl::init(false));
 
+static cl::opt ClLoadTracing("sanitizer-coverage-trace-loads",
+   cl::desc("Tracing of load instructions"),
+   cl::Hidden, cl::init(false));
+
+static cl::opt ClStoreTracing("sanitizer-coverage-trace-stores",
+cl::desc("Tracing of store instructions"),
+cl::Hidden, 

[PATCH] D108323: [asan] Added -inline-small-callbacks LLVM flag, which would force inline code for 8 and 16 byte data types when otherwise a callback would have been used.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

What's the code size implications?




Comment at: clang/test/CodeGen/asan-use-callbacks.cpp:15
 
-int deref(int *p) {
+long deref(long *p) {
   return *p;

As we introduce a difference in behavior for small and large accesses, 
I would extend this test to have 1, 2, 4, and 16-byte accesses. 



Comment at: llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp:310
+static cl::opt ClInlineSmallCallbacks(
+"asan-inline-small-callbacks",
+cl::desc("Inline callbacks for 8 and 16 byte types."), cl::Hidden,

The flag semantics are weird. We first say "use callbacks", then we say "but 
not for small callbacks". 
Perhaps, instead, introduce a flag 
asan-short-instrumentation-with-call-threshold
and when present use this flag for 8/16 instead of the 
asan-instrumentation-with-call-threshold?



Comment at: llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp:1749
 
+  if (ClInlineSmallCallbacks && AccessSizeIndex > 2) {
+UseCalls = false;

perhaps move this logic to where UseCalls is computed initially?
(see my other comment too)



Comment at: llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp:1751
+UseCalls = false;
+  }
+

for single-statement if bodies this code base does not use {}


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108323

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D106101: [asan] Slightly modified the documentation.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106101

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D104494: [dfsan] Replace dfs$ prefix with .dfsan suffix

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

Yey, great idea! :) 
(I am not reviewing the code; but the change looks straightforward)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104494

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D96120: [scudo] Port scudo sanitizer to Windows

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added reviewers: kcc, pcc, vitalybuka.
kcc added a comment.

We can't possibly maintain two variants of scudo. 
All effort is currently spent on the newer (standalone) version. 
I am afraid we will have to delete the older (non-standalone) variant entirely. 
(And the sooner the better)


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

https://reviews.llvm.org/D96120

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D89959: UBSAN: emit distinctive traps in trapping mode

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a reviewer: morehouse.
kcc added a comment.

did you consider approaches where the emitted code doesn't change, but the 
binary contains a debug-like metadata that corresponds to the trap instructions?
Matt (CC-ed) has a patch if this kind (for a different purpose) in the works .


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

https://reviews.llvm.org/D89959

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D84371: [DFSan] Add efficient fast16labels instrumentation mode.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

Yep, cool.
LGTM from me, but please get another pair if eyes (Vitaly?)




Comment at: clang/docs/DataFlowSanitizer.rst:182
+less CPU and code size overhead.  To use fast16labels instrumentation, you'll
+need to specify `-fsanitize=dataflow -mllvm -fast-16-labels` in your compile 
and
+link commands and use a modified API for creating and managing labels.

maybe -dataflow-fast-16-labels?



Comment at: clang/docs/DataFlowSanitizer.rst:201
+  int main(void) {
+int i = 1;
+int j = 2;

perhaps unconfuse the test a bit by using other constants 
  i = 100;
  j = 200;
  k = 300;


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84371



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D77477: tsan: don't instrument __attribute__((naked)) functions

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

The code is ok, but I'd like to see an ACK from Dmitry.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77477



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74150: Update hwasan docs to cover outlined checks and globals.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.

thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74150



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58195: [HWASAN] Updated HWASAN design document to better portray the chance of missing a bug.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM
and welcome back to the project! :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D58195



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54905: [AddressSanitizer] Add flag to disable linking with CXX runtime

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

weak new/delete may solve this particular problem, but may cause confusion to 
lots of other users, 
e.g. in cases when a user has overridden new/delete for non-essential reasons 
(e.g. debuging) and can disable the overrides in asan mode. 
With weak symbols such a user will never know they have a problem.


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

https://reviews.llvm.org/D54905



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54905: [AddressSanitizer] Add flag to disable linking with CXX runtime

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

In D54905#1312386 , @evgeny777 wrote:

> Unfortunately, this is not an option. I have very custom heap implementation 
> (in fact multiple heap types sharing contiguous memory block), so ASAN heap 
> can't be a drop-in replacement. I'm using manual poisoning and it works 
> pretty well,


It may appear to work well, but still be less powerful than what ASAN does for 
the regular malloc. 
Do you have readzones? quarantine? [de]allocation stack traces?

>   but have to disable C++ runtime each time I build with ASAN.

How do you do this now?

> Another problem is ASANing libcxx tests because of overridden new operator 
> (count_new.hpp). I think it makes sense to have counterpart for 
> `-fsanitize-link-c++-runtime`, no?

Is that related to https://github.com/google/sanitizers/issues/295 ?


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

https://reviews.llvm.org/D54905



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54905: [AddressSanitizer] Add flag to disable linking with CXX runtime

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

I am reluctant to add any new flags if there is any possibility to avoid doing 
so. 
Is there any other solution for your problem? 
E.g. you can disable the override of new/delete when building with asan.


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

https://reviews.llvm.org/D54905



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54604: Automatic variable initialization

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

Would it be possible to extend test/Sema/uninit-variables.c to verify that the 
new option
doesn't break -Wuninitialized?


Repository:
  rC Clang

https://reviews.llvm.org/D54604



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54473: [sanitizers] Initial implementation for -fsanitize=init-locals

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

I think you can safely abandon this change in favor of 
https://reviews.llvm.org/D54604 -- please join the review there.


Repository:
  rC Clang

https://reviews.llvm.org/D54473



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54604: Automatic variable initialization

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added reviewers: glider, vitalybuka, pcc, eugenis, vlad.tsyrklevich.
kcc added a comment.

exciting. adding more folks FYI and to help review


Repository:
  rC Clang

https://reviews.llvm.org/D54604



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D54473: [sanitizers] Initial implementation for -fsanitize=init-locals

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

This new flag inhibits the warnings from -Wuninitialized, right? 
While this is fine for experimenting (and I want to have this in ToT to enable 
wide experimentation)
we should clearly state (in the comments) that the final intent is to make the 
feature work together with -Wuninitialized.

Another thing that we will need (and not necessary in the first change) is to 
have fine grained controls over what we zero-initialize. 
We may want to make separate decisions for pointer/non-pointer scalars, PODs, 
arrays of {scalars, pointers, PODs}, etc.


Repository:
  rC Clang

https://reviews.llvm.org/D54473



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D50194: LLVM Proto Fuzzer - Run Functions on Suite of Inputs

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added inline comments.



Comment at: clang/tools/clang-fuzzer/handle-llvm/handle_llvm.cpp:128
+void RunFuncOnInputs(LLVMFunc f, int x) {
+  if (x) {
+for (int i = 0; i < NumArrays; i++)

looks like code duplication, also strange name for a variable: 'x'. 
Can't we just have one loop here and pass OptArrays/UnoptArrays as the 
parameter? 



Comment at: clang/tools/clang-fuzzer/handle-llvm/input_arrays.h:36
+  {1, 1, 2, 3, 2, 3, 0, 11, 10, 0, 7, 5, 3, 1, 18, 18, 18, 18, 0, 18, 18, 18, 
18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 
18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 
18, 18},
+  {0, 0, 2, 5, 4, 0, 2, 13, 12, 11, 0, 8, 6, 4, 2, 0, 20, 20, 20, 20, 0, 20, 
20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 
20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 
20, 20},
+  {1, 1, 0, 1, 6, 2, 4, 1, 14, 13, 12, 0, 9, 7, 5, 3, 1, 22, 22, 22, 22, 22, 
0, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 
22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 22, 
22, 22},

constants are not diverse enough. 


Repository:
  rC Clang

https://reviews.llvm.org/D50194



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49793: [AArch64] - return address signing

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added inline comments.



Comment at: include/clang/Frontend/CodeGenOptions.h:114
+Partial,// Sign the return address of functions that spill LR
+All // Sign the return address of all functions
+  };

what's the purpose of signing LR if it is not spilled? 


https://reviews.llvm.org/D49793



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47666: Refactored clang-fuzzer and added new (copy) files

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

Some feedback on the generated code:

  while (1){

let's not have the while loops inside the for loops for now. 
If the initial goal is to stress the loop optimizations (e.g. vectorizer), 
loops likes this are just a distraction

  for (int loop_ctr = 0

too verbose. Use 'i'm 'j', 'k'
also, alternate int, unsigned, size_t, long (later).

  a[436863498 % s]=1;

this is good for keeping the code UB-free, but it will render the tests 
non-vectorizable. 
need more tests that won't use `% s`

  void foo(int *a, size_t s) {

ok for a starter, but will need a more rich signature in the future versions.


Repository:
  rL LLVM

https://reviews.llvm.org/D47666



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D45996: [HWASan] Update HWASan assembly snippet in the docs

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rC Clang

https://reviews.llvm.org/D45996



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44801: Add the -fsanitize=shadow-call-stack flag

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.

LGTM modulo prolog vs prlogue and epilog vs epilogue

https://en.wiktionary.org/wiki/epilog says these are alternative spellings, so 
up to you.




Comment at: docs/ShadowCallStack.rst:14
+buffer overflows. It works by saving a function's return address to a
+separately allocated 'shadow call stack' in the function prolog and checking 
the
+return address on the stack against the shadow call stack in the function

kcc wrote:
> prologue/epilogue? 
> (it's your native tongue, not mine, though)
PTAL


Repository:
  rC Clang

https://reviews.llvm.org/D44801



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44801: Add the -fsanitize=shadow-call-stack flag

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

please also add a short comparison with Intel CET.


Repository:
  rC Clang

https://reviews.llvm.org/D44801



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44801: Add the -fsanitize=shadow-call-stack flag

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

[didn't look at the code yet, just at the docs]

Please add a docs section describing how to handle leaf functions. 
If they are not handled yet, no need to change the implementation in these 
pathches -- ok to do it later.




Comment at: docs/ShadowCallStack.rst:14
+buffer overflows. It works by saving a function's return address to a
+separately allocated 'shadow call stack' in the function prolog and checking 
the
+return address on the stack against the shadow call stack in the function

prologue/epilogue? 
(it's your native tongue, not mine, though)



Comment at: docs/ShadowCallStack.rst:20
+and trade-off consuming more memory for shorter function prologs and epilogs
+with fewer memory accesses.
+

Provide short comparison with RFG (more instructions, less memory, same racy 
attack)



Comment at: docs/ShadowCallStack.rst:38
+return address and bypass ShadowCallStack. Similarly, there is a time-of-check-
+to-time-of-use race in the function prolog where an attacker could overwrite 
the
+return address after it has been checked and before it has been returned to.

link to wikipedia maybe? 



Comment at: docs/ShadowCallStack.rst:41
+Modifying the call-return semantics to fix this on x86_64 would incur an
+unacceptable performance overhead.
+

... due to return branch predictor (or some such)



Comment at: docs/ShadowCallStack.rst:47
+not easily leak its address.
+
+Usage

Say something about attacks that first try to discover the secret location of 
the shadow call stack. 
side channels, thread spaying, whatever you have. 



Comment at: docs/ShadowCallStack.rst:74
+declaration to specify that the shadow call stack instrumentation should not be
+applied to that function, even if enabled globally.

Please add a section that shows the assembly for the following example: 

   int foo() {
  return bar() + 1;
   }


Repository:
  rC Clang

https://reviews.llvm.org/D44801



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43423: [SimplifyCFG] Create flag to disable simplifyCFG.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

We use function attributes in similar situations for asan/tsan/msan. 
Similar, but not equivalent, so I don't know if we must follow the same pattern 
here. 
The difference here is that we should keep the ability to turn optimization on 
and off from command line, regardless of what are the coverage instrumentation 
flags.

IIRC, the *function* metadata is not that easily stripped (as opposed to 
metadata attached to instructions).


https://reviews.llvm.org/D43423



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42874: [hwasan] Add a paragraph on stack instrumentation.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM++


https://reviews.llvm.org/D42874



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41417: [hwasan] Implement -fsanitize-recover=hwaddress.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM with a nit




Comment at: compiler-rt/lib/hwasan/hwasan.cc:255
 
-template
+template
 __attribute__((always_inline, nodebug))

I'd prefer enums to booleans, for better readability


https://reviews.llvm.org/D41417



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D40938: update hwasan docs

[Kostya Serebryany via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC320075: update hwasan docs (authored by kcc).

Changed prior to commit:
  https://reviews.llvm.org/D40938?vs=126001=126005#toc

Repository:
  rC Clang

https://reviews.llvm.org/D40938

Files:
  docs/HardwareAssistedAddressSanitizerDesign.rst


Index: docs/HardwareAssistedAddressSanitizerDesign.rst
===
--- docs/HardwareAssistedAddressSanitizerDesign.rst
+++ docs/HardwareAssistedAddressSanitizerDesign.rst
@@ -1,9 +1,9 @@
-=
-HardwareAssistedAddressSanitizer Design Documentation
-=
+===
+Hardware-assisted AddressSanitizer Design Documentation
+===
 
 This page is a design document for
-**HardwareAssistedAddressSanitizer** (or HWASAN)
+**hardware-assisted AddressSanitizer** (or **HWASAN**)
 a tool similar to :doc:`AddressSanitizer`,
 but based on partial hardware assistance.
 
@@ -23,7 +23,7 @@
 
 AArch64 has the `Address Tagging`_, a hardware feature that allows
 software to use 8 most significant bits of a 64-bit pointer as
-a tag. HardwareAssistedAddressSanitizer uses `Address Tagging`_
+a tag. HWASAN uses `Address Tagging`_
 to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
 but with smaller memory overhead and slightly different (mostly better)
 accuracy guarantees.
@@ -77,11 +77,26 @@
 
 Errors are generated by `__builtin_trap` and are handled by a signal handler.
 
+Attribute
+-
+
+HWASAN uses it's own LLVM IR Attribute `sanitize_hwaddress` and a matching
+C function attribute. An alternative would be to re-use ASAN's attribute
+`sanitize_address`. The reasons to use a separate attribute are:
+
+  * Users may need to disable ASAN but not HWASAN, or vise versa,
+because the tools have different trade-offs and compatibility issues.
+  * LLVM (ideally) does not use flags to decide which pass is being used,
+ASAN or HWASAN are being applied, based on the function attributes.
+
+This does mean that users of HWASAN may need to add the new attribute
+to the code that already uses the old attribute.
+
 
 Comparison with AddressSanitizer
 
 
-HardwareAssistedAddressSanitizer:
+HWASAN:
   * Is less portable than :doc:`AddressSanitizer`
 as it relies on hardware `Address Tagging`_ (AArch64).
 Address Tagging can be emulated with compiler instrumentation,
@@ -91,15 +106,16 @@
   * May have compatibility problems if the target code uses higher
 pointer bits for other purposes.
   * May require changes in the OS kernels (e.g. Linux seems to dislike
-tagged pointers passed from address space).
+tagged pointers passed from address space:
+https://www.kernel.org/doc/Documentation/arm64/tagged-pointers.txt).
   * **Does not require redzones to detect buffer overflows**,
 but the buffer overflow detection is probabilistic, with roughly
 `(2**K-1)/(2**K)` probability of catching a bug.
   * **Does not require quarantine to detect heap-use-after-free,
 or stack-use-after-return**.
 The detection is similarly probabilistic.
 
-The memory overhead of HardwareAssistedAddressSanitizer is expected to be much 
smaller
+The memory overhead of HWASAN is expected to be much smaller
 than that of AddressSanitizer:
 `1/N` extra memory for the shadow
 and some overhead due to `N`-aligning all objects.


Index: docs/HardwareAssistedAddressSanitizerDesign.rst
===
--- docs/HardwareAssistedAddressSanitizerDesign.rst
+++ docs/HardwareAssistedAddressSanitizerDesign.rst
@@ -1,9 +1,9 @@
-=
-HardwareAssistedAddressSanitizer Design Documentation
-=
+===
+Hardware-assisted AddressSanitizer Design Documentation
+===
 
 This page is a design document for
-**HardwareAssistedAddressSanitizer** (or HWASAN)
+**hardware-assisted AddressSanitizer** (or **HWASAN**)
 a tool similar to :doc:`AddressSanitizer`,
 but based on partial hardware assistance.
 
@@ -23,7 +23,7 @@
 
 AArch64 has the `Address Tagging`_, a hardware feature that allows
 software to use 8 most significant bits of a 64-bit pointer as
-a tag. HardwareAssistedAddressSanitizer uses `Address Tagging`_
+a tag. HWASAN uses `Address Tagging`_
 to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
 but with smaller memory overhead and slightly different (mostly better)
 accuracy guarantees.
@@ -77,11 +77,26 @@
 
 Errors are generated by `__builtin_trap` and are handled by a signal handler.
 
+Attribute
+-
+
+HWASAN uses it's own LLVM IR 

[PATCH] D40938: update hwasan docs

[Kostya Serebryany via Phabricator via cfe-commits]

kcc updated this revision to Diff 126001.
kcc added a comment.

mention https://www.kernel.org/doc/Documentation/arm64/tagged-pointers.txt


Repository:
  rC Clang

https://reviews.llvm.org/D40938

Files:
  docs/HardwareAssistedAddressSanitizerDesign.rst


Index: docs/HardwareAssistedAddressSanitizerDesign.rst
===
--- docs/HardwareAssistedAddressSanitizerDesign.rst
+++ docs/HardwareAssistedAddressSanitizerDesign.rst
@@ -1,9 +1,9 @@
-=
-HardwareAssistedAddressSanitizer Design Documentation
-=
+===
+Hardware-assisted AddressSanitizer Design Documentation
+===
 
 This page is a design document for
-**HardwareAssistedAddressSanitizer** (or HWASAN)
+**hardware-assisted AddressSanitizer** (or **HWASAN**)
 a tool similar to :doc:`AddressSanitizer`,
 but based on partial hardware assistance.
 
@@ -23,7 +23,7 @@
 
 AArch64 has the `Address Tagging`_, a hardware feature that allows
 software to use 8 most significant bits of a 64-bit pointer as
-a tag. HardwareAssistedAddressSanitizer uses `Address Tagging`_
+a tag. HWASAN uses `Address Tagging`_
 to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
 but with smaller memory overhead and slightly different (mostly better)
 accuracy guarantees.
@@ -77,11 +77,26 @@
 
 Errors are generated by `__builtin_trap` and are handled by a signal handler.
 
+Attribute
+-
+
+HWASAN uses it's own LLVM IR Attribute `sanitize_hwaddress` and a matching
+C function attribute. An alternative would be to re-use ASAN's attribute
+`sanitize_address`. The reasons to use a separate attribute are:
+
+  * Users may need to disable ASAN but not HWASAN, or vise versa,
+because the tools have different trade-offs and compatibility issues.
+  * LLVM (ideally) does not use flags to decide which pass is being used,
+ASAN or HWASAN are being applied, based on the function attributes.
+
+This does mean that users of HWASAN may need to add the new attribute
+to the code that already uses the old attribute.
+
 
 Comparison with AddressSanitizer
 
 
-HardwareAssistedAddressSanitizer:
+HWASAN:
   * Is less portable than :doc:`AddressSanitizer`
 as it relies on hardware `Address Tagging`_ (AArch64).
 Address Tagging can be emulated with compiler instrumentation,
@@ -91,15 +106,16 @@
   * May have compatibility problems if the target code uses higher
 pointer bits for other purposes.
   * May require changes in the OS kernels (e.g. Linux seems to dislike
-tagged pointers passed from address space).
+tagged pointers passed from address space:
+https://www.kernel.org/doc/Documentation/arm64/tagged-pointers.txt).
   * **Does not require redzones to detect buffer overflows**,
 but the buffer overflow detection is probabilistic, with roughly
 `(2**K-1)/(2**K)` probability of catching a bug.
   * **Does not require quarantine to detect heap-use-after-free,
 or stack-use-after-return**.
 The detection is similarly probabilistic.
 
-The memory overhead of HardwareAssistedAddressSanitizer is expected to be much 
smaller
+The memory overhead of HWASAN is expected to be much smaller
 than that of AddressSanitizer:
 `1/N` extra memory for the shadow
 and some overhead due to `N`-aligning all objects.


Index: docs/HardwareAssistedAddressSanitizerDesign.rst
===
--- docs/HardwareAssistedAddressSanitizerDesign.rst
+++ docs/HardwareAssistedAddressSanitizerDesign.rst
@@ -1,9 +1,9 @@
-=
-HardwareAssistedAddressSanitizer Design Documentation
-=
+===
+Hardware-assisted AddressSanitizer Design Documentation
+===
 
 This page is a design document for
-**HardwareAssistedAddressSanitizer** (or HWASAN)
+**hardware-assisted AddressSanitizer** (or **HWASAN**)
 a tool similar to :doc:`AddressSanitizer`,
 but based on partial hardware assistance.
 
@@ -23,7 +23,7 @@
 
 AArch64 has the `Address Tagging`_, a hardware feature that allows
 software to use 8 most significant bits of a 64-bit pointer as
-a tag. HardwareAssistedAddressSanitizer uses `Address Tagging`_
+a tag. HWASAN uses `Address Tagging`_
 to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
 but with smaller memory overhead and slightly different (mostly better)
 accuracy guarantees.
@@ -77,11 +77,26 @@
 
 Errors are generated by `__builtin_trap` and are handled by a signal handler.
 
+Attribute
+-
+
+HWASAN uses it's own LLVM IR Attribute `sanitize_hwaddress` and a matching
+C function attribute. An 

[PATCH] D40936: Hardware-assisted AddressSanitizer (clang part).

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM
please give at least Aleksey a chance to review as well.


https://reviews.llvm.org/D40936



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D40938: update hwasan docs

[Kostya Serebryany via Phabricator via cfe-commits]

kcc created this revision.
Herald added a subscriber: cfe-commits.

- use more readable name
- document the hwasan attribute


Repository:
  rC Clang

https://reviews.llvm.org/D40938

Files:
  docs/HardwareAssistedAddressSanitizerDesign.rst


Index: docs/HardwareAssistedAddressSanitizerDesign.rst
===
--- docs/HardwareAssistedAddressSanitizerDesign.rst
+++ docs/HardwareAssistedAddressSanitizerDesign.rst
@@ -1,9 +1,9 @@
-=
-HardwareAssistedAddressSanitizer Design Documentation
-=
+===
+Hardware-assisted AddressSanitizer Design Documentation
+===
 
 This page is a design document for
-**HardwareAssistedAddressSanitizer** (or HWASAN)
+**hardware-assisted AddressSanitizer** (or **HWASAN**)
 a tool similar to :doc:`AddressSanitizer`,
 but based on partial hardware assistance.
 
@@ -23,7 +23,7 @@
 
 AArch64 has the `Address Tagging`_, a hardware feature that allows
 software to use 8 most significant bits of a 64-bit pointer as
-a tag. HardwareAssistedAddressSanitizer uses `Address Tagging`_
+a tag. HWASAN uses `Address Tagging`_
 to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
 but with smaller memory overhead and slightly different (mostly better)
 accuracy guarantees.
@@ -77,11 +77,26 @@
 
 Errors are generated by `__builtin_trap` and are handled by a signal handler.
 
+Attribute
+-
+
+HWASAN uses it's own LLVM IR Attribute `sanitize_hwaddress` and a matching
+C function attribute. An alternative would be to re-use ASAN's attribute
+`sanitize_address`. The reasons to use a separate attribute are:
+
+  * Users may need to disable ASAN but not HWASAN, or vise versa,
+because the tools have different trade-offs and compatibility issues.
+  * LLVM (ideally) does not use flags to decide which pass is being used,
+ASAN or HWASAN are being applied, based on the function attributes.
+
+This does mean that users of HWASAN may need to add the new attribute
+to the code that already uses the old attribute.
+
 
 Comparison with AddressSanitizer
 
 
-HardwareAssistedAddressSanitizer:
+HWASAN:
   * Is less portable than :doc:`AddressSanitizer`
 as it relies on hardware `Address Tagging`_ (AArch64).
 Address Tagging can be emulated with compiler instrumentation,
@@ -99,7 +114,7 @@
 or stack-use-after-return**.
 The detection is similarly probabilistic.
 
-The memory overhead of HardwareAssistedAddressSanitizer is expected to be much 
smaller
+The memory overhead of HWASAN is expected to be much smaller
 than that of AddressSanitizer:
 `1/N` extra memory for the shadow
 and some overhead due to `N`-aligning all objects.


Index: docs/HardwareAssistedAddressSanitizerDesign.rst
===
--- docs/HardwareAssistedAddressSanitizerDesign.rst
+++ docs/HardwareAssistedAddressSanitizerDesign.rst
@@ -1,9 +1,9 @@
-=
-HardwareAssistedAddressSanitizer Design Documentation
-=
+===
+Hardware-assisted AddressSanitizer Design Documentation
+===
 
 This page is a design document for
-**HardwareAssistedAddressSanitizer** (or HWASAN)
+**hardware-assisted AddressSanitizer** (or **HWASAN**)
 a tool similar to :doc:`AddressSanitizer`,
 but based on partial hardware assistance.
 
@@ -23,7 +23,7 @@
 
 AArch64 has the `Address Tagging`_, a hardware feature that allows
 software to use 8 most significant bits of a 64-bit pointer as
-a tag. HardwareAssistedAddressSanitizer uses `Address Tagging`_
+a tag. HWASAN uses `Address Tagging`_
 to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
 but with smaller memory overhead and slightly different (mostly better)
 accuracy guarantees.
@@ -77,11 +77,26 @@
 
 Errors are generated by `__builtin_trap` and are handled by a signal handler.
 
+Attribute
+-
+
+HWASAN uses it's own LLVM IR Attribute `sanitize_hwaddress` and a matching
+C function attribute. An alternative would be to re-use ASAN's attribute
+`sanitize_address`. The reasons to use a separate attribute are:
+
+  * Users may need to disable ASAN but not HWASAN, or vise versa,
+because the tools have different trade-offs and compatibility issues.
+  * LLVM (ideally) does not use flags to decide which pass is being used,
+ASAN or HWASAN are being applied, based on the function attributes.
+
+This does mean that users of HWASAN may need to add the new attribute
+to the code that already uses the old attribute.
+
 
 Comparison with AddressSanitizer
 
 

[PATCH] D40568: design document for a hardware-assisted memory safety (HWAMS) tool, similar to AddressSanitizer

[Kostya Serebryany via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC319684: design document for a hardware-assisted memory 
safety (HWAMS) tool, similar to… (authored by kcc).

Changed prior to commit:
  https://reviews.llvm.org/D40568?vs=125045=125398#toc

Repository:
  rC Clang

https://reviews.llvm.org/D40568

Files:
  docs/HardwareAssistedAddressSanitizerDesign.rst
  docs/index.rst

Index: docs/HardwareAssistedAddressSanitizerDesign.rst
===
--- docs/HardwareAssistedAddressSanitizerDesign.rst
+++ docs/HardwareAssistedAddressSanitizerDesign.rst
@@ -0,0 +1,123 @@
+=
+HardwareAssistedAddressSanitizer Design Documentation
+=
+
+This page is a design document for
+**HardwareAssistedAddressSanitizer** (or HWASAN)
+a tool similar to :doc:`AddressSanitizer`,
+but based on partial hardware assistance.
+
+The document is a draft, suggestions are welcome.
+
+
+Introduction
+
+
+:doc:`AddressSanitizer`
+tags every 8 bytes of the application memory with a 1 byte tag (using *shadow memory*),
+uses *redzones* to find buffer-overflows and
+*quarantine* to find use-after-free.
+The redzones, the quarantine, and, to a less extent, the shadow, are the
+sources of AddressSanitizer's memory overhead.
+See the `AddressSanitizer paper`_ for details.
+
+AArch64 has the `Address Tagging`_, a hardware feature that allows
+software to use 8 most significant bits of a 64-bit pointer as
+a tag. HardwareAssistedAddressSanitizer uses `Address Tagging`_
+to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
+but with smaller memory overhead and slightly different (mostly better)
+accuracy guarantees.
+
+Algorithm
+=
+* Every heap/stack/global memory object is forcibly aligned by `N` bytes
+  (`N` is e.g. 16 or 64)
+* For every such object a random `K`-bit tag `T` is chosen (`K` is e.g. 4 or 8)
+* The pointer to the object is tagged with `T`.
+* The memory for the object is also tagged with `T`
+  (using a `N=>1` shadow memory)
+* Every load and store is instrumented to read the memory tag and compare it
+  with the pointer tag, exception is raised on tag mismatch.
+
+Instrumentation
+===
+
+Memory Accesses
+---
+All memory accesses are prefixed with a call to a run-time function.
+The function encodes the type and the size of access in its name;
+it receives the address as a parameter, e.g. `__hwasan_load4(void *ptr)`;
+it loads the memory tag, compares it with the
+pointer tag, and executes `__builtin_trap` (or calls `__hwasan_error_load4(void *ptr)`) on mismatch.
+
+It's possible to inline this callback too.
+
+Heap
+
+
+Tagging the heap memory/pointers is done by `malloc`.
+This can be based on any malloc that forces all objects to be N-aligned.
+
+Stack
+-
+
+Special compiler instrumentation is required to align the local variables
+by N, tag the memory and the pointers.
+Stack instrumentation is expected to be a major source of overhead,
+but could be optional.
+TODO: details.
+
+Globals
+---
+
+TODO: details.
+
+Error reporting
+---
+
+Errors are generated by `__builtin_trap` and are handled by a signal handler.
+
+
+Comparison with AddressSanitizer
+
+
+HardwareAssistedAddressSanitizer:
+  * Is less portable than :doc:`AddressSanitizer`
+as it relies on hardware `Address Tagging`_ (AArch64).
+Address Tagging can be emulated with compiler instrumentation,
+but it will require the instrumentation to remove the tags before
+any load or store, which is infeasible in any realistic environment
+that contains non-instrumented code.
+  * May have compatibility problems if the target code uses higher
+pointer bits for other purposes.
+  * May require changes in the OS kernels (e.g. Linux seems to dislike
+tagged pointers passed from address space).
+  * **Does not require redzones to detect buffer overflows**,
+but the buffer overflow detection is probabilistic, with roughly
+`(2**K-1)/(2**K)` probability of catching a bug.
+  * **Does not require quarantine to detect heap-use-after-free,
+or stack-use-after-return**.
+The detection is similarly probabilistic.
+
+The memory overhead of HardwareAssistedAddressSanitizer is expected to be much smaller
+than that of AddressSanitizer:
+`1/N` extra memory for the shadow
+and some overhead due to `N`-aligning all objects.
+
+
+Related Work
+
+* `SPARC ADI`_ implements a similar tool mostly in hardware.
+* `Effective and Efficient Memory Protection Using Dynamic Tainting`_ discusses
+  similar approaches ("lock & key").
+* `Watchdog`_ discussed a heavier, but still somewhat similar
+  "lock & key" approach.
+* *TODO: add more "related work" links. Suggestions are welcome.*
+
+
+.. _Watchdog: 

[PATCH] D40568: design document for a hardware-assisted memory safety (HWAMS) tool, similar to AddressSanitizer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc updated this revision to Diff 125045.
kcc added a comment.

Rename the new tool to HWASAN


Repository:
  rC Clang

https://reviews.llvm.org/D40568

Files:
  docs/HardwareAssistedAddressSanitizerDesign.rst
  docs/index.rst

Index: docs/index.rst
===
--- docs/index.rst
+++ docs/index.rst
@@ -84,6 +84,7 @@
PTHInternals
PCHInternals
ItaniumMangleAbiTags
+   HardwareAssistedAddressSanitizerDesign.rst
 
 
 Indices and tables
Index: docs/HardwareAssistedAddressSanitizerDesign.rst
===
--- /dev/null
+++ docs/HardwareAssistedAddressSanitizerDesign.rst
@@ -0,0 +1,123 @@
+=
+HardwareAssistedAddressSanitizer Design Documentation
+=
+
+This page is a design document for
+**HardwareAssistedAddressSanitizer** (or HWASAN)
+a tool similar to :doc:`AddressSanitizer`,
+but based on partial hardware assistance.
+
+The document is a draft, suggestions are welcome.
+
+
+Introduction
+
+
+:doc:`AddressSanitizer`
+tags every 8 bytes of the application memory with a 1 byte tag (using *shadow memory*),
+uses *redzones* to find buffer-overflows and
+*quarantine* to find use-after-free.
+The redzones, the quarantine, and, to a less extent, the shadow, are the
+sources of AddressSanitizer's memory overhead.
+See the `AddressSanitizer paper`_ for details.
+
+AArch64 has the `Address Tagging`_, a hardware feature that allows
+software to use 8 most significant bits of a 64-bit pointer as
+a tag. HardwareAssistedAddressSanitizer uses `Address Tagging`_
+to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
+but with smaller memory overhead and slightly different (mostly better)
+accuracy guarantees.
+
+Algorithm
+=
+* Every heap/stack/global memory object is forcibly aligned by `N` bytes
+  (`N` is e.g. 16 or 64)
+* For every such object a random `K`-bit tag `T` is chosen (`K` is e.g. 4 or 8)
+* The pointer to the object is tagged with `T`.
+* The memory for the object is also tagged with `T`
+  (using a `N=>1` shadow memory)
+* Every load and store is instrumented to read the memory tag and compare it
+  with the pointer tag, exception is raised on tag mismatch.
+
+Instrumentation
+===
+
+Memory Accesses
+---
+All memory accesses are prefixed with a call to a run-time function.
+The function encodes the type and the size of access in its name;
+it receives the address as a parameter, e.g. `__hwasan_load4(void *ptr)`;
+it loads the memory tag, compares it with the
+pointer tag, and executes `__builtin_trap` (or calls `__hwasan_error_load4(void *ptr)`) on mismatch.
+
+It's possible to inline this callback too.
+
+Heap
+
+
+Tagging the heap memory/pointers is done by `malloc`.
+This can be based on any malloc that forces all objects to be N-aligned.
+
+Stack
+-
+
+Special compiler instrumentation is required to align the local variables
+by N, tag the memory and the pointers.
+Stack instrumentation is expected to be a major source of overhead,
+but could be optional.
+TODO: details.
+
+Globals
+---
+
+TODO: details.
+
+Error reporting
+---
+
+Errors are generated by `__builtin_trap` and are handled by a signal handler.
+
+
+Comparison with AddressSanitizer
+
+
+HardwareAssistedAddressSanitizer:
+  * Is less portable than :doc:`AddressSanitizer`
+as it relies on hardware `Address Tagging`_ (AArch64).
+Address Tagging can be emulated with compiler instrumentation,
+but it will require the instrumentation to remove the tags before
+any load or store, which is infeasible in any realistic environment
+that contains non-instrumented code.
+  * May have compatibility problems if the target code uses higher
+pointer bits for other purposes.
+  * May require changes in the OS kernels (e.g. Linux seems to dislike
+tagged pointers passed from address space).
+  * **Does not require redzones to detect buffer overflows**,
+but the buffer overflow detection is probabilistic, with roughly
+`(2**K-1)/(2**K)` probability of catching a bug.
+  * **Does not require quarantine to detect heap-use-after-free,
+or stack-use-after-return**.
+The detection is similarly probabilistic.
+
+The memory overhead of HardwareAssistedAddressSanitizer is expected to be much smaller
+than that of AddressSanitizer:
+`1/N` extra memory for the shadow
+and some overhead due to `N`-aligning all objects.
+
+
+Related Work
+
+* `SPARC ADI`_ implements a similar tool mostly in hardware.
+* `Effective and Efficient Memory Protection Using Dynamic Tainting`_ discusses
+  similar approaches ("lock & key").
+* `Watchdog`_ discussed a heavier, but still somewhat similar
+  "lock & key" approach.
+* *TODO: add more "related work" links. Suggestions are welcome.*
+
+
+.. 

[PATCH] D40568: design document for a hardware-assisted memory safety (HWAMS) tool, similar to AddressSanitizer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc updated this revision to Diff 124797.
kcc added a comment.

rephrase the sources of asan overhead


Repository:
  rC Clang

https://reviews.llvm.org/D40568

Files:
  docs/TaggedAddressSanitizerDesign.rst

Index: docs/TaggedAddressSanitizerDesign.rst
===
--- /dev/null
+++ docs/TaggedAddressSanitizerDesign.rst
@@ -0,0 +1,125 @@
+===
+TaggedAddressSanitizer Design Documentation
+===
+
+This page is a preliminary design document for
+a **hardware-assisted memory safety** (HWAMS) tool,
+similar to :doc:`AddressSanitizer`.
+
+The name **TaggedAddressSanitizer** or TASAN
+(alternative: **HardwareAssistedAddressSanitizer** or HWASAN)
+and the rest of the document,
+are *early draft*, suggestions are welcome.
+
+
+Introduction
+
+
+:doc:`AddressSanitizer`
+tags every 8 bytes of the application memory with a 1 byte tag (using *shadow memory*),
+uses *redzones* to find buffer-overflows and
+*quarantine* to find use-after-free.
+The redzones, the quarantine, and, to a less extent, the shadow, are the
+sources of AddressSanitizer's memory overhead.
+See the `AddressSanitizer paper`_ for details.
+
+AArch64 has the `Address Tagging`_, a hardware feature that allows
+software to use 8 most significant bits of a 64-bit pointer as
+a tag. TaggedAddressSanitizer uses `Address Tagging`_
+to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
+but with smaller memory overhead and slightly different (mostly better)
+accuracy guarantees.
+
+Algorithm
+=
+* Every heap/stack/global memory object is forcibly aligned by `N` bytes
+  (`N` is e.g. 16 or 64)
+* For every such object a random `K`-bit tag `T` is chosen (`K` is e.g. 4 or 8)
+* The pointer to the object is tagged with `T`.
+* The memory for the object is also tagged with `T`
+  (using a `N=>1` shadow memory)
+* Every load and store is instrumented to read the memory tag and compare it
+  with the pointer tag, exception is raised on tag mismatch.
+
+Instrumentation
+===
+
+Memory Accesses
+---
+All memory accesses are prefixed with a call to a run-time function.
+The function encodes the type and the size of access in its name;
+it receives the address as a parameter, e.g. `__hwams_load4(void *ptr)`;
+it loads the memory tag, compares it with the
+pointer tag, and executes `__builtin_trap` (or calls `__hwams_error_load4(void *ptr)`) on mismatch.
+
+It's possible to inline this callback too.
+
+Heap
+
+
+Tagging the heap memory/pointers is done by `malloc`.
+This can be based on any malloc that forces all objects to be N-aligned.
+
+Stack
+-
+
+Special compiler instrumentation is required to align the local variables
+by N, tag the memory and the pointers.
+Stack instrumentation is expected to be a major source of overhead,
+but could be optional.
+TODO: details.
+
+Globals
+---
+
+TODO: details.
+
+Error reporting
+---
+
+Errors are generated by `__builtin_trap` and are handled by a signal handler.
+
+
+Comparison with AddressSanitizer
+
+
+TaggedAddressSanitizer:
+  * Is less portable than :doc:`AddressSanitizer`
+as it relies on hardware `Address Tagging`_ (AArch64).
+Address Tagging can be emulated with compiler instrumentation,
+but it will require the instrumentation to remove the tags before
+any load or store, which is infeasible in any realistic environment
+that contains non-instrumented code.
+  * May have compatibility problems if the target code uses higher
+pointer bits for other purposes.
+  * May require changes in the OS kernels (e.g. Linux seems to dislike
+tagged pointers passed from address space).
+  * Does not require redzones to detect buffer overflows,
+but the buffer overflow detection is probabilistic, with roughly
+`(2**K-1)/(2**K)` probability of catching a bug.
+  * Does not require quarantine to detect heap-use-after-free,
+or stack-use-after-return.
+The detection is similarly probabilistic.
+
+The memory overhead of TaggedAddressSanitizer is expected to be much smaller
+than that of AddressSanitizer:
+`1/N` extra memory for the shadow
+and some overhead due to `N`-aligning all objects.
+
+
+Related Work
+
+* `SPARC ADI`_ implements a similar tool mostly in hardware.
+* `Effective and Efficient Memory Protection Using Dynamic Tainting`_ discusses
+  similar approaches ("lock & key").
+* `Watchdog`_ discussed a heavier, but still somewhat similar
+  "lock & key" approach.
+* *TODO: add more "related work" links. Suggestions are welcome.*
+
+
+.. _Watchdog: http://www.cis.upenn.edu/acg/papers/isca12_watchdog.pdf
+.. _Effective and Efficient Memory Protection Using Dynamic Tainting: https://www.cc.gatech.edu/~orso/papers/clause.doudalis.orso.prvulovic.pdf
+.. _SPARC ADI: 

[PATCH] D40568: design document for a hardware-assisted memory safety (HWAMS) tool, similar to AddressSanitizer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc updated this revision to Diff 124691.
kcc added a comment.

mention alternatives for memory access instrumentation


Repository:
  rC Clang

https://reviews.llvm.org/D40568

Files:
  docs/TaggedAddressSanitizerDesign.rst

Index: docs/TaggedAddressSanitizerDesign.rst
===
--- /dev/null
+++ docs/TaggedAddressSanitizerDesign.rst
@@ -0,0 +1,125 @@
+===
+TaggedAddressSanitizer Design Documentation
+===
+
+This page is a preliminary design document for
+a **hardware-assisted memory safety** (HWAMS) tool,
+similar to :doc:`AddressSanitizer`.
+
+The name **TaggedAddressSanitizer** or TASAN
+(alternative: **HardwareAssistedAddressSanitizer** or HWASAN)
+and the rest of the document,
+are *early draft*, suggestions are welcome.
+
+
+Introduction
+
+
+:doc:`AddressSanitizer`
+tags every 8 bytes of the application memory with a 1 byte tag (using *shadow memory*),
+uses *redzones* to find buffer-overflows and
+*quarantine* to find use-after-free.
+The shadow, the redzones, and the quarantine are the
+major sources of AddressSanitizer's memory overhead.
+See the `AddressSanitizer paper`_ for details.
+
+AArch64 has the `Address Tagging`_, a hardware feature that allows
+software to use 8 most significant bits of a 64-bit pointer as
+a tag. TaggedAddressSanitizer uses `Address Tagging`_
+to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
+but with smaller memory overhead and slightly different (mostly better)
+accuracy guarantees.
+
+Algorithm
+=
+* Every heap/stack/global memory object is forcibly aligned by `N` bytes
+  (`N` is e.g. 16 or 64)
+* For every such object a random `K`-bit tag `T` is chosen (`K` is e.g. 4 or 8)
+* The pointer to the object is tagged with `T`.
+* The memory for the object is also tagged with `T`
+  (using a `N=>1` shadow memory)
+* Every load and store is instrumented to read the memory tag and compare it
+  with the pointer tag, exception is raised on tag mismatch.
+
+Instrumentation
+===
+
+Memory Accesses
+---
+All memory accesses are prefixed with a call to a run-time function.
+The function encodes the type and the size of access in its name;
+it receives the address as a parameter, e.g. `__hwams_load4(void *ptr)`;
+it loads the memory tag, compares it with the
+pointer tag, and executes `__builtin_trap` (or calls `__hwams_error_load4(void *ptr)`) on mismatch.
+
+It's possible to inline this callback too.
+
+Heap
+
+
+Tagging the heap memory/pointers is done by `malloc`.
+This can be based on any malloc that forces all objects to be N-aligned.
+
+Stack
+-
+
+Special compiler instrumentation is required to align the local variables
+by N, tag the memory and the pointers.
+Stack instrumentation is expected to be a major source of overhead,
+but could be optional.
+TODO: details.
+
+Globals
+---
+
+TODO: details.
+
+Error reporting
+---
+
+Errors are generated by `__builtin_trap` and are handled by a signal handler.
+
+
+Comparison with AddressSanitizer
+
+
+TaggedAddressSanitizer:
+  * Is less portable than :doc:`AddressSanitizer`
+as it relies on hardware `Address Tagging`_ (AArch64).
+Address Tagging can be emulated with compiler instrumentation,
+but it will require the instrumentation to remove the tags before
+any load or store, which is infeasible in any realistic environment
+that contains non-instrumented code.
+  * May have compatibility problems if the target code uses higher
+pointer bits for other purposes.
+  * May require changes in the OS kernels (e.g. Linux seems to dislike
+tagged pointers passed from address space).
+  * Does not require redzones to detect buffer overflows,
+but the buffer overflow detection is probabilistic, with roughly
+`(2**K-1)/(2**K)` probability of catching a bug.
+  * Does not require quarantine to detect heap-use-after-free,
+or stack-use-after-return.
+The detection is similarly probabilistic.
+
+The memory overhead of TaggedAddressSanitizer is expected to be much smaller
+than that of AddressSanitizer:
+`1/N` extra memory for the shadow
+and some overhead due to `N`-aligning all objects.
+
+
+Related Work
+
+* `SPARC ADI`_ implements a similar tool mostly in hardware.
+* `Effective and Efficient Memory Protection Using Dynamic Tainting`_ discusses
+  similar approaches ("lock & key").
+* `Watchdog`_ discussed a heavier, but still somewhat similar
+  "lock & key" approach.
+* *TODO: add more "related work" links. Suggestions are welcome.*
+
+
+.. _Watchdog: http://www.cis.upenn.edu/acg/papers/isca12_watchdog.pdf
+.. _Effective and Efficient Memory Protection Using Dynamic Tainting: https://www.cc.gatech.edu/~orso/papers/clause.doudalis.orso.prvulovic.pdf
+.. _SPARC ADI: 

[PATCH] D40568: design document for a hardware-assisted memory safety (HWAMS) tool, similar to AddressSanitizer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added inline comments.



Comment at: docs/TaggedAddressSanitizerDesign.rst:22
+*quarantine* to find use-after-free.
+The shadow, the redzones, and the quarantine are the
+major sources of AddressSanitizer's memory overhead.

davidxl wrote:
> What is the overhead of redzones compared with shadow memory?
depends.
shadow is 1/9 of all memory.
redzones largely depend on the allocation patterns. 
If most heap allocations are big, the combined redzones are tiny, and vise 
versa 




Comment at: docs/TaggedAddressSanitizerDesign.rst:49
+---
+All memory accesses are prefixed with a call to a run-time function
+that loads the memory tag, compares it with the

davidxl wrote:
> a real runtime call or it will be lowered into inline sequence?
at least in the initial implementation -- yes. 
Since this is aarc64-specific, the call/ret should be relatively cheap. 
But of course nothing prevents us from inlining if we see a need for it. 


Repository:
  rC Clang

https://reviews.llvm.org/D40568



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D40568: design document for a hardware-assisted memory safety (HWAMS) tool, similar to AddressSanitizer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc marked an inline comment as done.
kcc added inline comments.



Comment at: docs/TaggedAddressSanitizerDesign.rst:2
+===
+TaggedAddressSanitizer Design Documentation
+===

eugenis wrote:
> I vote for HardwareAssistedAddressSanitizer, or hwasan.
Added hwasan as an alternative. 
I dislike it less then tasan. 
Let's wait for other suggestions before renaming. 



Comment at: docs/TaggedAddressSanitizerDesign.rst:101
+and some overhead due to `N`-aligning all objects.
+
+

eugenis wrote:
> Mention the system calls problem with tagged pointers.
added 
   May require changes in the OS kernels (e.g. Linux seems to dislike
tagged pointers passed from address space).


Repository:
  rC Clang

https://reviews.llvm.org/D40568



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D40568: design document for a hardware-assisted memory safety (HWAMS) tool, similar to AddressSanitizer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc updated this revision to Diff 124637.
kcc added a comment.

addressed comments


Repository:
  rC Clang

https://reviews.llvm.org/D40568

Files:
  docs/TaggedAddressSanitizerDesign.rst

Index: docs/TaggedAddressSanitizerDesign.rst
===
--- /dev/null
+++ docs/TaggedAddressSanitizerDesign.rst
@@ -0,0 +1,122 @@
+===
+TaggedAddressSanitizer Design Documentation
+===
+
+This page is a preliminary design document for
+a **hardware-assisted memory safety** (HWAMS) tool,
+similar to :doc:`AddressSanitizer`.
+
+The name **TaggedAddressSanitizer** or TASAN
+(alternative: **HardwareAssistedAddressSanitizer** or HWASAN)
+and the rest of the document,
+are *early draft*, suggestions are welcome.
+
+
+Introduction
+
+
+:doc:`AddressSanitizer`
+tags every 8 bytes of the application memory with a 1 byte tag (using *shadow memory*),
+uses *redzones* to find buffer-overflows and
+*quarantine* to find use-after-free.
+The shadow, the redzones, and the quarantine are the
+major sources of AddressSanitizer's memory overhead.
+See the `AddressSanitizer paper`_ for details.
+
+AArch64 has the `Address Tagging`_, a hardware feature that allows
+software to use 8 most significant bits of a 64-bit pointer as
+a tag. TaggedAddressSanitizer uses `Address Tagging`_
+to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
+but with smaller memory overhead and slightly different (mostly better)
+accuracy guarantees.
+
+Algorithm
+=
+* Every heap/stack/global memory object is forcibly aligned by `N` bytes
+  (`N` is e.g. 16 or 64)
+* For every such object a random `K`-bit tag `T` is chosen (`K` is e.g. 4 or 8)
+* The pointer to the object is tagged with `T`.
+* The memory for the object is also tagged with `T`
+  (using a `N=>1` shadow memory)
+* Every load and store is instrumented to read the memory tag and compare it
+  with the pointer tag, exception is raised on tag mismatch.
+
+Instrumentation
+===
+
+Memory Accesses
+---
+All memory accesses are prefixed with a call to a run-time function
+that loads the memory tag, compares it with the
+pointer tag, and executes `__builtin_trap` on mismatch.
+The function name encodes the type and the size of access, e.g. `__hwams_load4(void *ptr)`.
+
+Heap
+
+
+Tagging the heap memory/pointers is done by `malloc`.
+This can be based on any malloc that forces all objects to be N-aligned.
+
+Stack
+-
+
+Special compiler instrumentation is required to align the local variables
+by N, tag the memory and the pointers.
+Stack instrumentation is expected to be a major source of overhead,
+but could be optional.
+TODO: details.
+
+Globals
+---
+
+TODO: details.
+
+Error reporting
+---
+
+Errors are generated by `__builtin_trap` and are handled by a signal handler.
+
+
+Comparison with AddressSanitizer
+
+
+TaggedAddressSanitizer:
+  * Is less portable than :doc:`AddressSanitizer`
+as it relies on hardware `Address Tagging`_ (AArch64).
+Address Tagging can be emulated with compiler instrumentation,
+but it will require the instrumentation to remove the tags before
+any load or store, which is infeasible in any realistic environment
+that contains non-instrumented code.
+  * May have compatibility problems if the target code uses higher
+pointer bits for other purposes.
+  * May require changes in the OS kernels (e.g. Linux seems to dislike
+tagged pointers passed from address space).
+  * Does not require redzones to detect buffer overflows,
+but the buffer overflow detection is probabilistic, with roughly
+`(2**K-1)/(2**K)` probability of catching a bug.
+  * Does not require quarantine to detect heap-use-after-free,
+or stack-use-after-return.
+The detection is similarly probabilistic.
+
+The memory overhead of TaggedAddressSanitizer is expected to be much smaller
+than that of AddressSanitizer:
+`1/N` extra memory for the shadow
+and some overhead due to `N`-aligning all objects.
+
+
+Related Work
+
+* `SPARC ADI`_ implements a similar tool mostly in hardware.
+* `Effective and Efficient Memory Protection Using Dynamic Tainting`_ discusses
+  similar approaches ("lock & key").
+* `Watchdog`_ discussed a heavier, but still somewhat similar
+  "lock & key" approach.
+* *TODO: add more "related work" links. Suggestions are welcome.*
+
+
+.. _Watchdog: http://www.cis.upenn.edu/acg/papers/isca12_watchdog.pdf
+.. _Effective and Efficient Memory Protection Using Dynamic Tainting: https://www.cc.gatech.edu/~orso/papers/clause.doudalis.orso.prvulovic.pdf
+.. _SPARC ADI: https://lazytyped.blogspot.com/2017/09/getting-started-with-adi.html
+.. _AddressSanitizer paper: https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf
+.. _Address Tagging: 

[PATCH] D40568: design document for a hardware-assisted memory safety (HWAMS) tool, similar to AddressSanitizer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc updated this revision to Diff 124604.
kcc added a comment.

minor edit (explained shadow)


Repository:
  rC Clang

https://reviews.llvm.org/D40568

Files:
  docs/TaggedAddressSanitizerDesign.rst

Index: docs/TaggedAddressSanitizerDesign.rst
===
--- /dev/null
+++ docs/TaggedAddressSanitizerDesign.rst
@@ -0,0 +1,118 @@
+===
+TaggedAddressSanitizer Design Documentation
+===
+
+This page is a preliminary design document for
+a **hardware-assisted memory safety** (HWAMS) tool,
+similar to :doc:`AddressSanitizer`.
+
+The name **TaggedAddressSanitizer** and the rest of the document,
+are *early draft*, suggestions are welcome.
+
+
+Introduction
+
+
+:doc:`AddressSanitizer`
+tags every 8 bytes of the application memory with a 1 byte tag (using *shadow memory*),
+uses *redzones* to find buffer-overflows and
+*quarantine* to find use-after-free.
+The shadow, the redzones, and the quarantine are the
+major sources of AddressSanitizer's memory overhead.
+See the `AddressSanitizer paper`_ for details.
+
+AArch64 has the `Address Tagging`_, a hardware feature that allows
+software to use the 8 most significant bits of a 64-bit pointer as
+a tag. TaggedAddressSanitizer uses `Address Tagging`_
+to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
+but with smaller memory overhead and slightly different (mostly better)
+accuracy guarantees.
+
+Algorithm
+=
+* Every heap/stack/global memory object is forcibly aligned by `N` bytes
+  (`N` is e.g. 16 or 64)
+* For every such object a random `K`-bit tag `T` is chosen (`K` is e.g. 4 or 8)
+* The pointer to the object is tagged with `T`.
+* The memory for the object is also tagged with `T`
+  (using a `N=>1` shadow memory)
+* Every load and store is instrumented to read the memory tag and compare it
+  with the pointer tag, exception is raised on tag mismatch.
+
+Instrumentation
+===
+
+Memory Accesses
+---
+All memory accesses are prefixed with a call to a run-time function
+that loads the memory tag, compares it with the
+pointer tag, and executes `__builtin_trap` on mismatch.
+The function name encodes the type and the size of access, e.g. `__hwams_load4(void *ptr)`.
+
+Heap
+
+
+Tagging the heap memory/pointers is done by `malloc`.
+This can be based on any malloc that forces all objects to be N-aligned.
+
+Stack
+-
+
+Special compiler instrumentation is required to align the local variables
+by N, tag the memory and the pointers.
+Stack instrumentation is expected to be a major source of overhead,
+but could be optional.
+TODO: details.
+
+Globals
+---
+
+TODO: details.
+
+Error reporting
+---
+
+Errors are generated by `__builtin_trap` and are handled by a signal handler.
+
+
+Comparison with AddressSanitizer
+
+
+TaggedAddressSanitizer:
+  * Is less portable than :doc:`AddressSanitizer`
+as it relies on hardware `Address Tagging`_ (AArch64).
+Address Tagging can be emulated with compiler instrumentation,
+but it will require the instrumentation to remove the tags before
+any load or store, which is infeasible in any realistic environment
+that contains non-instrumented code.
+  * May have compatibility problems if the target code uses higher
+pointer bits for other purposes.
+  * Does not require redzones to detect buffer overflows,
+but the buffer overflow detection is probabilistic, with roughly
+`(2**K-1)/(2**K)` probability of catching a bug.
+  * Does not require quarantine to detect heap-use-after-free,
+or stack-use-after-return.
+The detection is similarly probabilistic.
+
+The memory overhead of TaggedAddressSanitizer is expected to be much smaller
+than that of AddressSanitizer:
+`1/N` extra memory for the shadow
+and some overhead due to `N`-aligning all objects.
+
+
+Related Work
+
+* `SPARC ADI`_ implements a similar tool mostly in hardware.
+* `Effective and Efficient Memory Protection Using Dynamic Tainting`_ discusses
+  similar approaches ("lock & key").
+* `Watchdog`_ discussed a heavier, but still somewhat similar
+  "lock & key" approach.
+* *TODO: add more "related work" links. Suggestions are welcome.*
+
+
+.. _Watchdog: http://www.cis.upenn.edu/acg/papers/isca12_watchdog.pdf
+.. _Effective and Efficient Memory Protection Using Dynamic Tainting: https://www.cc.gatech.edu/~orso/papers/clause.doudalis.orso.prvulovic.pdf
+.. _SPARC ADI: https://lazytyped.blogspot.com/2017/09/getting-started-with-adi.html
+.. _AddressSanitizer paper: https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf
+.. _Address Tagging: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/ch12s05s01.html
+
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D40568: design document for a hardware-assisted memory safety (HWAMS) tool, similar to AddressSanitizer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc created this revision.
Herald added subscribers: cfe-commits, fedor.sergeev.

preliminary design document for a hardware-assisted memory safety (HWAMS) tool, 
similar to AddressSanitizer
The name TaggedAddressSanitizer and the rest of the document, are early draft, 
suggestions are welcome.

The code will follow shortly.


Repository:
  rC Clang

https://reviews.llvm.org/D40568

Files:
  docs/TaggedAddressSanitizerDesign.rst
  docs/index.rst

Index: docs/index.rst
===
--- docs/index.rst
+++ docs/index.rst
@@ -84,6 +84,7 @@
PTHInternals
PCHInternals
ItaniumMangleAbiTags
+   TaggedAddressSanitizerDesign
 
 
 Indices and tables
Index: docs/TaggedAddressSanitizerDesign.rst
===
--- /dev/null
+++ docs/TaggedAddressSanitizerDesign.rst
@@ -0,0 +1,118 @@
+===
+TaggedAddressSanitizer Design Documentation
+===
+
+This page is a preliminary design document for
+a **hardware-assisted memory safety** (HWAMS) tool,
+similar to :doc:`AddressSanitizer`.
+
+The name **TaggedAddressSanitizer** and the rest of the document,
+are *early draft*, suggestions are welcome.
+
+
+Introduction
+
+
+:doc:`AddressSanitizer`
+tags every 8 bytes of the application memory with a 1 byte tag,
+uses *redzones* to find buffer-overflows and
+*quarantine* to find use-after-free.
+The shadow, the redzones, and the quarantine are the
+major sources of AddressSanitizer's memory overhead.
+See the `AddressSanitizer paper`_ for details.
+
+AArch64 has the `Address Tagging`_, a hardware feature that allows
+software to use the 8 most significant bits of a 64-bit pointer as
+a tag. TaggedAddressSanitizer uses `Address Tagging`_
+to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
+but with smaller memory overhead and slightly different (mostly better)
+accuracy guarantees.
+
+Algorithm
+=
+* Every heap/stack/global memory object is forcibly aligned by `N` bytes
+  (`N` is e.g. 16 or 64)
+* For every such object a random `K`-bit tag `T` is chosen (`K` is e.g. 4 or 8)
+* The pointer to the object is tagged with `T`.
+* The memory for the object is also tagged with `T`
+  (using a `N=>1` shadow memory)
+* Every load and store is instrumented to read the memory tag and compare it
+  with the pointer tag, exception is raised on tag mismatch.
+
+Instrumentation
+===
+
+Memory Accesses
+---
+All memory accesses are prefixed with a call to a run-time function
+that loads the memory tag, compares it with the
+pointer tag, and executes `__builtin_trap` on mismatch.
+The function name encodes the type and the size of access, e.g. `__hwams_load4(void *ptr)`.
+
+Heap
+
+
+Tagging the heap memory/pointers is done by `malloc`.
+This can be based on any malloc that forces all objects to be N-aligned.
+
+Stack
+-
+
+Special compiler instrumentation is required to align the local variables
+by N, tag the memory and the pointers.
+Stack instrumentation is expected to be a major source of overhead,
+but could be optional.
+TODO: details.
+
+Globals
+---
+
+TODO: details.
+
+Error reporting
+---
+
+Errors are generated by `__builtin_trap` and are handled by a signal handler.
+
+
+Comparison with AddressSanitizer
+
+
+TaggedAddressSanitizer:
+  * Is less portable than :doc:`AddressSanitizer`
+as it relies on hardware `Address Tagging`_ (AArch64).
+Address Tagging can be emulated with compiler instrumentation,
+but it will require the instrumentation to remove the tags before
+any load or store, which is infeasible in any realistic environment
+that contains non-instrumented code.
+  * May have compatibility problems if the target code uses higher
+pointer bits for other purposes.
+  * Does not require redzones to detect buffer overflows,
+but the buffer overflow detection is probabilistic, with roughly
+`(2**K-1)/(2**K)` probability of catching a bug.
+  * Does not require quarantine to detect heap-use-after-free,
+or stack-use-after-return.
+The detection is similarly probabilistic.
+
+The memory overhead of TaggedAddressSanitizer is expected to be much smaller
+than that of AddressSanitizer:
+`1/N` extra memory for the shadow
+and some overhead due to `N`-aligning all objects.
+
+
+Related Work
+
+* `SPARC ADI`_ implements a similar tool mostly in hardware.
+* `Effective and Efficient Memory Protection Using Dynamic Tainting`_ discusses
+  similar approaches ("lock & key").
+* `Watchdog`_ discussed a heavier, but still somewhat similar
+  "lock & key" approach.
+* *TODO: add more "related work" links. Suggestions are welcome.*
+
+
+.. _Watchdog: http://www.cis.upenn.edu/acg/papers/isca12_watchdog.pdf
+.. _Effective and Efficient Memory Protection Using Dynamic Tainting: 

[PATCH] D38853: [clang-format] Allow building fuzzer with OSS-Fuzz flags.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a reviewer: bogner.
kcc accepted this revision.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM

+Justin FYI

Please also take a look at llvm-isel-fuzzer, which I've just added to oss-fuzz


https://reviews.llvm.org/D38853



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D38812: [clang-fuzzer] Allow linking with any fuzzing engine.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM


https://reviews.llvm.org/D38812



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D38642: [clang-fuzzer] Allow building without coverage instrumentation.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

In https://reviews.llvm.org/D38642#891125, @morehouse wrote:

> In https://reviews.llvm.org/D38642#891074, @kcc wrote:
>
> > If you can *easily* share main() with the one in LLVM -- do it, otherwise 
> > don't bother.
>
>
> Does the fuzzer main come from LLVM or compiler-rt now?  There's still 
> FuzzerMain.cpp in LLVM, but I'm not sure if we should be using that or not.


Don't reuse FuzzerMain.cpp. 
There is llvm/tools/llvm-isel-fuzzer/DummyISelFuzzer.cpp which your main() 
duplicates, but these are in different projects (llvm vs clang) so perhaps it's 
ok.


https://reviews.llvm.org/D38642



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D38642: [clang-fuzzer] Allow building without coverage instrumentation.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a reviewer: vitalybuka.
kcc added a comment.

conceptually ok, but please let Vitaly review the cmake part.


https://reviews.llvm.org/D38642



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D38642: [clang-fuzzer] Allow building without coverage instrumentation.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

grrr. I am sorry, I've just contradicted myself. :( 
The goal here is to build the fuzz targets always and use them as tests, which 
includes building with any toolchain, including toolchains that don't support 
-fsanitize=fuzzer
your original change actually solved this. 
If you can *easily* share main() with the one in LLVM -- do it, otherwise don't 
bother.


https://reviews.llvm.org/D38642



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D38642: [clang-fuzzer] Allow building without coverage instrumentation.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

We often suggest to code owners to implement their own dummy main to run fuzz 
targets as regression tests. 
But for ourselves (LLVM) this recommendations makes less sense since libFuzzer 
is part of LLVM and we can use it's main directly.


https://reviews.llvm.org/D38642



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D38642: [clang-fuzzer] Allow building without coverage instrumentation.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

>> Will we be able to reuse some of Justin's code instead of creating one more 
>> main() function?
> 
> This reuses the code that Justin moved to FuzzMutate/FuzzerCLI.  That's why 
> the main is so short.  But perhaps we could move the main itself into 
> FuzzerCLI?

Yes, having one common main makes sense, but see below.

>> Or, why not link with libFuzzer (-fsanitize=fuzzer at link time) even if we 
>> don't us einstrumentation at compile time?
> 
> When I tried this, I got undefined references to all kinds of 
> `__sanitizer_cov_*` symbols.

I'd like to know more. 
At least simple cases work fine:

  clang++ ~/llvm/projects/compiler-rt/test/fuzzer/SimpleTest.cpp -std=c++11  -c 
&& clang++ SimpleTest.o -fsanitize=fuzzer 


https://reviews.llvm.org/D38642



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D38642: [clang-fuzzer] Allow building without coverage instrumentation.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

It's not about coverage instrumentation (not) being present, but about 
libFuzzer's main() being present, right? 
Will we be able to reuse some of Justin's code instead of creating one more 
main() function? 
Or, why not link with libFuzzer (-fsanitize=fuzzer at link time) even if we 
don't us einstrumentation at compile time?


https://reviews.llvm.org/D38642



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.

LGTM


https://reviews.llvm.org/D37156



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added inline comments.



Comment at: clang/lib/Driver/SanitizerArgs.cpp:297
 CoverageTraceCmp | CoveragePCTable;
+#if !defined(__APPLE__)
+// Due to TLS differences, stack depth tracking is disabled on Mac.

please use if(SomeCondition) instead of #if

In general: 99% of cases where you may want to use #if -- you shouldn't



Comment at: 
compiler-rt/lib/sanitizer_common/sanitizer_coverage_libcdep_new.cc:20
 #include "sanitizer_symbolizer.h"
+#include 
 

no standard hearder in this files. Just use the 'uptr' type. 


https://reviews.llvm.org/D37156



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a reviewer: george.karpenkov.
kcc added a comment.

+George, in case he knows about __attribute__((tls_model("initial-exec"))) on 
Mac




Comment at: 
compiler-rt/lib/sanitizer_common/sanitizer_coverage_libcdep_new.cc:218
+SANITIZER_INTERFACE_ATTRIBUTE SANITIZER_WEAK_ATTRIBUTE
+__attribute__((tls_model("initial-exec")))
+thread_local uintptr_t __sancov_lowest_stack;

I wonder if this going to work on Mac. 


https://reviews.llvm.org/D37156



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM


https://reviews.llvm.org/D37156



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D37156: [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

Did you check this on something other than the unit tests? 
E.g. a couple of benchmarks from fuzzer-test-suite?




Comment at: llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp:177
 
+bool IsLeafFunc(const Function ) {
+  for (const BasicBlock  : F.getBasicBlockList())

we already have a linear scan in SanitizerCoverageModule::runOnFunction -- 
don't introduce a second one. 
Also, there is InvokeInst in addition to CallInst, see the loop in 
runOnFunction.

You can simply extend the loop in runOnFunction to set a flag if the function 
has non-intrin calls/ invokes 


https://reviews.llvm.org/D37156



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36839: [SanitizerCoverage] Add stack depth tracing instrumentation.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

Please also write a lit test for test/DeepRecursionTest.cpp (e.g. 
test/deep-recursion.test)


Repository:
  rL LLVM

https://reviews.llvm.org/D36839



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36882: [clang-proto-fuzzer] Allow user-specified compiler arguments.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

Update the README file please (with a text similar to this commit message)




Comment at: cfe/trunk/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp:32
+  for (int I = 1; I < *argc; I++) {
+if (strcmp((*argv)[I], "-ignore_remaining_args=1") == 0) {
+  for (I++; I < *argc; I++)

[remark, feel free to ignore]
the "break;" here is redundant, and thus the {} too, i.e. you can keep the code 
shorter.
Whether it will make it more readable is debatable.  


Repository:
  rL LLVM

https://reviews.llvm.org/D36882



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36635: Add a Dockerfile for clang-proto-fuzzer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

I'd avoid such extra complexity, after all this is just an example. 
One can force the full rebuild with --no-cache. It'll take just a bit more time 
since most of the time is consumed by the compiler builds. 
BTW, my old svn (1.8.8, Ubuntu 14.04) does't have "info --show-item revision"


https://reviews.llvm.org/D36635



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36635: Add a Dockerfile for clang-proto-fuzzer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added inline comments.



Comment at: tools/clang-fuzzer/Dockerfile:22
+# Get LLVM
+RUN svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
+RUN cd llvm/tools && svn co http://llvm.org/svn/llvm-project/cfe/trunk clang 
-r $(cd ../ && svn info | grep Revision | awk '{print $2}')

morehouse wrote:
> What if the latest revision breaks the build?
Then we will know that! 

I hope to have clang-proto-fuzzer on a bot of some kind at some point, maybe on 
oss-fuzz, so we will know if the TotT is broken



Comment at: tools/clang-fuzzer/Dockerfile:24
+RUN cd llvm/tools && svn co http://llvm.org/svn/llvm-project/cfe/trunk clang 
-r $(cd ../ && svn info | grep Revision | awk '{print $2}')
+RUN cd llvm/projects && svn co 
http://llvm.org/svn/llvm-project/compiler-rt/trunk clang -r $(cd ../ && svn 
info | grep Revision | awk '{print $2}')
+# Build plain LLVM (stage 0)

morehouse wrote:
> Should this be `svn co ... compiler-rt`?
Of course, fixed. !
Very surprisingly, this still worked!


https://reviews.llvm.org/D36635



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36635: Add a Dockerfile for clang-proto-fuzzer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc updated this revision to Diff 110810.
kcc added a comment.

fix 'svn co' command (apparently it did not matter though)


https://reviews.llvm.org/D36635

Files:
  tools/clang-fuzzer/Dockerfile
  tools/clang-fuzzer/README.txt


Index: tools/clang-fuzzer/README.txt
===
--- tools/clang-fuzzer/README.txt
+++ tools/clang-fuzzer/README.txt
@@ -59,6 +59,8 @@
 -DCLANG_ENABLE_PROTO_FUZZER=ON
   ninja clang-proto-fuzzer clang-proto-to-cxx
 
+This directory also contains a Dockerfile which sets up all required
+dependencies and builds the fuzzers.
 
 =
  Running the fuzzers
Index: tools/clang-fuzzer/Dockerfile
===
--- /dev/null
+++ tools/clang-fuzzer/Dockerfile
@@ -0,0 +1,37 @@
+#===- llvm/tools/clang/tools/clang-fuzzer 
-===//
+#
+# The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+#
+#===--===//
+# Produces an image that builds clang-proto-fuzzer
+FROM ubuntu:16.04
+RUN apt-get update -y
+RUN apt-get install -y autoconf automake libtool curl make g++ unzip wget git \
+binutils liblzma-dev libz-dev python-all cmake ninja-build subversion \
+pkg-config docbook2x
+
+WORKDIR /root
+
+# Get protobuf
+RUN wget -qO- 
https://github.com/google/protobuf/releases/download/v3.3.0/protobuf-cpp-3.3.0.tar.gz
 | tar zxf -
+RUN cd protobuf-3.3.0 && ./autogen.sh && ./configure && make -j $(nproc) && 
make check -j $(nproc) && make install && ldconfig
+# Get LLVM
+RUN svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
+RUN cd llvm/tools && svn co http://llvm.org/svn/llvm-project/cfe/trunk clang 
-r $(cd ../ && svn info | grep Revision | awk '{print $2}')
+RUN cd llvm/projects && svn co 
http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt -r $(cd ../ && 
svn info | grep Revision | awk '{print $2}')
+# Build plain LLVM (stage 0)
+RUN mkdir build0 && cd build0 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release 
../llvm && ninja
+# Configure instrumented LLVM (stage 1)
+RUN mkdir build1 && cd build1 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release 
../llvm \
+-DLLVM_ENABLE_ASSERTIONS=ON \
+-DCMAKE_C_COMPILER=`pwd`/../build0/bin/clang \
+-DCMAKE_CXX_COMPILER=`pwd`/../build0/bin/clang++ \
+-DLLVM_USE_SANITIZE_COVERAGE=YES \
+-DLLVM_USE_SANITIZER=Address -DCLANG_ENABLE_PROTO_FUZZER=ON
+# Build the fuzzers
+RUN cd build1 && ninja clang-fuzzer
+RUN cd build1 && ninja clang-proto-fuzzer
+RUN cd build1 && ninja clang-proto-to-cxx


Index: tools/clang-fuzzer/README.txt
===
--- tools/clang-fuzzer/README.txt
+++ tools/clang-fuzzer/README.txt
@@ -59,6 +59,8 @@
 -DCLANG_ENABLE_PROTO_FUZZER=ON
   ninja clang-proto-fuzzer clang-proto-to-cxx
 
+This directory also contains a Dockerfile which sets up all required
+dependencies and builds the fuzzers.
 
 =
  Running the fuzzers
Index: tools/clang-fuzzer/Dockerfile
===
--- /dev/null
+++ tools/clang-fuzzer/Dockerfile
@@ -0,0 +1,37 @@
+#===- llvm/tools/clang/tools/clang-fuzzer -===//
+#
+# The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+#
+#===--===//
+# Produces an image that builds clang-proto-fuzzer
+FROM ubuntu:16.04
+RUN apt-get update -y
+RUN apt-get install -y autoconf automake libtool curl make g++ unzip wget git \
+binutils liblzma-dev libz-dev python-all cmake ninja-build subversion \
+pkg-config docbook2x
+
+WORKDIR /root
+
+# Get protobuf
+RUN wget -qO- https://github.com/google/protobuf/releases/download/v3.3.0/protobuf-cpp-3.3.0.tar.gz | tar zxf -
+RUN cd protobuf-3.3.0 && ./autogen.sh && ./configure && make -j $(nproc) && make check -j $(nproc) && make install && ldconfig
+# Get LLVM
+RUN svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
+RUN cd llvm/tools && svn co http://llvm.org/svn/llvm-project/cfe/trunk clang -r $(cd ../ && svn info | grep Revision | awk '{print $2}')
+RUN cd llvm/projects && svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt -r $(cd ../ && svn info | grep Revision | awk '{print $2}')
+# Build plain LLVM (stage 0)
+RUN mkdir build0 && cd build0 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release ../llvm && ninja
+# Configure instrumented LLVM (stage 1)
+RUN mkdir build1 && cd build1 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release ../llvm \
+-DLLVM_ENABLE_ASSERTIONS=ON \
+-DCMAKE_C_COMPILER=`pwd`/../build0/bin/clang \
+-DCMAKE_CXX_COMPILER=`pwd`/../build0/bin/clang++ \

[PATCH] D36635: Add a Dockerfile for clang-proto-fuzzer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc created this revision.

Add a Dockerfile for clang-proto-fuzzer


https://reviews.llvm.org/D36635

Files:
  tools/clang-fuzzer/Dockerfile
  tools/clang-fuzzer/README.txt


Index: tools/clang-fuzzer/README.txt
===
--- tools/clang-fuzzer/README.txt
+++ tools/clang-fuzzer/README.txt
@@ -59,6 +59,8 @@
 -DCLANG_ENABLE_PROTO_FUZZER=ON
   ninja clang-proto-fuzzer clang-proto-to-cxx
 
+This directory also contains a Dockerfile which sets up all required
+dependencies and builds the fuzzers.
 
 =
  Running the fuzzers
Index: tools/clang-fuzzer/Dockerfile
===
--- /dev/null
+++ tools/clang-fuzzer/Dockerfile
@@ -0,0 +1,37 @@
+#===- llvm/tools/clang/tools/clang-fuzzer 
-===//
+#
+# The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+#
+#===--===//
+# Produces an image that builds clang-proto-fuzzer
+FROM ubuntu:16.04
+RUN apt-get update -y
+RUN apt-get install -y autoconf automake libtool curl make g++ unzip wget git \
+binutils liblzma-dev libz-dev python-all cmake ninja-build subversion \
+pkg-config docbook2x
+
+WORKDIR /root
+
+# Get protobuf
+RUN wget -qO- 
https://github.com/google/protobuf/releases/download/v3.3.0/protobuf-cpp-3.3.0.tar.gz
 | tar zxf -
+RUN cd protobuf-3.3.0 && ./autogen.sh && ./configure && make -j $(nproc) && 
make check -j $(nproc) && make install && ldconfig
+# Get LLVM
+RUN svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
+RUN cd llvm/tools && svn co http://llvm.org/svn/llvm-project/cfe/trunk clang 
-r $(cd ../ && svn info | grep Revision | awk '{print $2}')
+RUN cd llvm/projects && svn co 
http://llvm.org/svn/llvm-project/compiler-rt/trunk clang -r $(cd ../ && svn 
info | grep Revision | awk '{print $2}')
+# Build plain LLVM (stage 0)
+RUN mkdir build0 && cd build0 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release 
../llvm && ninja
+# Configure instrumented LLVM (stage 1)
+RUN mkdir build1 && cd build1 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release 
../llvm \
+-DLLVM_ENABLE_ASSERTIONS=ON \
+-DCMAKE_C_COMPILER=`pwd`/../build0/bin/clang \
+-DCMAKE_CXX_COMPILER=`pwd`/../build0/bin/clang++ \
+-DLLVM_USE_SANITIZE_COVERAGE=YES \
+-DLLVM_USE_SANITIZER=Address -DCLANG_ENABLE_PROTO_FUZZER=ON
+# Build the fuzzers
+RUN cd build1 && ninja clang-fuzzer
+RUN cd build1 && ninja clang-proto-fuzzer
+RUN cd build1 && ninja clang-proto-to-cxx


Index: tools/clang-fuzzer/README.txt
===
--- tools/clang-fuzzer/README.txt
+++ tools/clang-fuzzer/README.txt
@@ -59,6 +59,8 @@
 -DCLANG_ENABLE_PROTO_FUZZER=ON
   ninja clang-proto-fuzzer clang-proto-to-cxx
 
+This directory also contains a Dockerfile which sets up all required
+dependencies and builds the fuzzers.
 
 =
  Running the fuzzers
Index: tools/clang-fuzzer/Dockerfile
===
--- /dev/null
+++ tools/clang-fuzzer/Dockerfile
@@ -0,0 +1,37 @@
+#===- llvm/tools/clang/tools/clang-fuzzer -===//
+#
+# The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+#
+#===--===//
+# Produces an image that builds clang-proto-fuzzer
+FROM ubuntu:16.04
+RUN apt-get update -y
+RUN apt-get install -y autoconf automake libtool curl make g++ unzip wget git \
+binutils liblzma-dev libz-dev python-all cmake ninja-build subversion \
+pkg-config docbook2x
+
+WORKDIR /root
+
+# Get protobuf
+RUN wget -qO- https://github.com/google/protobuf/releases/download/v3.3.0/protobuf-cpp-3.3.0.tar.gz | tar zxf -
+RUN cd protobuf-3.3.0 && ./autogen.sh && ./configure && make -j $(nproc) && make check -j $(nproc) && make install && ldconfig
+# Get LLVM
+RUN svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
+RUN cd llvm/tools && svn co http://llvm.org/svn/llvm-project/cfe/trunk clang -r $(cd ../ && svn info | grep Revision | awk '{print $2}')
+RUN cd llvm/projects && svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk clang -r $(cd ../ && svn info | grep Revision | awk '{print $2}')
+# Build plain LLVM (stage 0)
+RUN mkdir build0 && cd build0 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release ../llvm && ninja
+# Configure instrumented LLVM (stage 1)
+RUN mkdir build1 && cd build1 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release ../llvm \
+-DLLVM_ENABLE_ASSERTIONS=ON \
+-DCMAKE_C_COMPILER=`pwd`/../build0/bin/clang \
+-DCMAKE_CXX_COMPILER=`pwd`/../build0/bin/clang++ \
+-DLLVM_USE_SANITIZE_COVERAGE=YES \
+

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.

LGTM with a couple if nits in the README

Thanks!




Comment at: clang/tools/clang-fuzzer/README.txt:11
+class, producing valid C++ programs in the process.  As a result,
+clang-proto-fuzzer is better at stressing deeper layers of Clang.
+

.. of of Clang and LLVM



Comment at: clang/tools/clang-fuzzer/README.txt:36
+=
+Install the necessary dependencies:
+- binutils  // needed for libprotobuf-mutator

(linux-only instructions)



Comment at: clang/tools/clang-fuzzer/README.txt:51
+
+Then build the clang-proto-fuzzer target.
+

You may also build clang-fuzzer with this setup 


https://reviews.llvm.org/D36324



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

Looks good!
Now, please add a clang/tools/clang-fuzzer/README.txt describing how to build 
the fuzzers (both the old one and the new one) and how to run them.
For the new one explain how to install the deps


https://reviews.llvm.org/D36324



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

In https://reviews.llvm.org/D36324#835415, @morehouse wrote:

> In https://reviews.llvm.org/D36324#834660, @kcc wrote:
>
> > Why do we need LLVM_ENABLE_RTTI=ON here?
>
>
> Attempting to build without it yields all kinds of protobuf errors.  For 
> example:
>  F4944099: image.png 


This is very strange, I'd like to understand more about this LLVM_ENABLE_RTTI. 
ideally, we should avoid it.


https://reviews.llvm.org/D36324



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

Why do we need LLVM_ENABLE_RTTI=ON here?


https://reviews.llvm.org/D36324



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a reviewer: bogner.
kcc added a comment.

+bogner@ FYI




Comment at: clang/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp:25
+
+static void MaybePrint(const std::string ) {
+  static const char *env = getenv("CXXFUZZ_PRINT");

this is debug code, not worth having here, plz remove



Comment at: clang/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp:34
+  MaybePrint(S);
+  HandleCXX(S, {"-O2", "-mllvm", "-scalar-evolution-max-arith-depth=4"});
+  if (getenv("CXX_FUZZ_MORE")) {

Remove "-mllvm", "-scalar-evolution-max-arith-depth=4".
It's there as a workaround for a performance bug 
(https://bugs.llvm.org/show_bug.cgi?id=33494) but it shouldn't be here. 



Comment at: clang/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp:35
+  HandleCXX(S, {"-O2", "-mllvm", "-scalar-evolution-max-arith-depth=4"});
+  if (getenv("CXX_FUZZ_MORE")) {
+HandleCXX(S, {"-O1", "-triple", "arm-apple-darwin10", "-mllvm",

Remove this section. 
In a later change, please allow to change the tripple (and any other flags) 
similar to https://reviews.llvm.org/D36275



Comment at: clang/tools/clang-fuzzer/cxx_proto.proto:16
+
+syntax = "proto2";
+//option cc_api_version = 2;

vitalybuka wrote:
> vitalybuka wrote:
> > I'd suggest proto3
> proto3 has no required, to avoid backward compatibility issues.
> Same is useful for us, we don't wont to discard corpus if we drop some field 
> in the future.
I'm afraid it's much more convenient to have 'required' here. 
How else could you express a binary op node? 



Comment at: clang/tools/clang-fuzzer/cxx_proto.proto:93
+}
+
+package clang_fuzzer;

vitalybuka wrote:
> morehouse wrote:
> > vitalybuka wrote:
> > > message CxxInput {
> > >   required Function f = 1;
> > >   required int/enum opt_level = 2;
> > >   required enum tripple = 3;
> > >   required scalar-evolution-max-arith-depth ...
> > > }
> > Interesting idea.  This would allow for protobuf-mutator to choose 
> > different option combinations, if I understand correctly.
> > 
> > Is that worth adding to this initial patch, though?
> yes, instead of CXX_FUZZ_MORE
For now, keep it as is, please (see my other comment about flags) 


https://reviews.llvm.org/D36324



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36324: Integrate Kostya's clang-proto-fuzzer with LLVM.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

In https://reviews.llvm.org/D36324#832271, @thakis wrote:

> Why should this be part of llvm? This seems to come with very heavy 
> dependencies (protobuf), and LLVM has historically tried to minimize the 
> number of things it depends on.


This fuzzer has already uncovered a few llvm bugs, so I hope it can be useful 
directly. 
But more than that, I hope that a ready-to-use integration with structure-aware 
fuzzing will allow other researchers to experiment. 
Having it as a side patch (bit-rotten in a few weeks after creation) will 
discourage most of the potential researchers from experiments.

I agree we don't want to bring heavy deps to LLVM, but this patch (AFAICT) 
doesn't bring any new deps to the default build. (at least this is the intent)


https://reviews.llvm.org/D36324



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33277: [Clang][x86][Inline Asm] - Enum support for MS syntax

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

Hi. 
This patch causes the msan bots to complain. Please fix or revert ASAP. 
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/6702/steps/check-clang%20msan/logs/stdio
Testing: 0 .. 10..
FAIL: Clang :: CodeGen/ms_this.cpp (2142 of 11057)

- TEST 'Clang :: CodeGen/ms_this.cpp' FAILED 

Script:
---

/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/clang
 -cc1 -internal-isystem 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/clang/6.0.0/include
 -nostdsysteminc -triple x86_64-pc-win32 -fasm-blocks -emit-llvm 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/test/CodeGen/ms_this.cpp
 -o - | 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build_msan/./bin/FileCheck
 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/test/CodeGen/ms_this.cpp
--

Exit Code: 2

Command Output (stderr):


4713==WARNING: MemorySanitizer: use-of-uninitialized-value
--

  #0 0x3143ba3 in (anonymous 
namespace)::X86AsmParser::ParseIntelIdentifier(llvm::MCExpr const*&, 
llvm::StringRef&, llvm::InlineAsmIdentifierInfo&, bool, llvm::SMLoc&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:1664:7
  #1 0x313f288 in (anonymous 
namespace)::X86AsmParser::ParseIntelExpression((anonymous 
namespace)::X86AsmParser::IntelExprStateMachine&, llvm::SMLoc&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:1440:13
  #2 0x31389e7 in (anonymous 
namespace)::X86AsmParser::ParseIntelBracExpression(unsigned int, llvm::SMLoc, 
long, bool, unsigned int) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:1555:7
  #3 0x31307f8 in ParseIntelOperand 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:1961:12
  #4 0x31307f8 in (anonymous namespace)::X86AsmParser::ParseOperand() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:1225
  #5 0x3118cda in (anonymous 
namespace)::X86AsmParser::ParseInstruction(llvm::ParseInstructionInfo&, 
llvm::StringRef, llvm::SMLoc, 
llvm::SmallVectorImpl >&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp:2510:44
  #6 0x4bb9a48 in (anonymous namespace)::AsmParser::parseStatement((anonymous 
namespace)::ParseStatementInfo&, llvm::MCAsmParserSemaCallback*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/lib/MC/MCParser/AsmParser.cpp:2034:42
  #7 0x4ba63a3 in (anonymous namespace)::AsmParser::parseMSInlineAsm(void*, 
std::__1::basic_string&, unsigned int&, unsigned int&, 
llvm::SmallVectorImpl >&, 
llvm::SmallVectorImpl >&, 
llvm::SmallVectorImpl >&, llvm::MCInstrInfo const*, llvm::MCInstPrinter 
const*, llvm::MCAsmParserSemaCallback&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/lib/MC/MCParser/AsmParser.cpp:5343:25
  #8 0x82f1100 in 
clang::Parser::ParseMicrosoftAsmStatement(clang::SourceLocation) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseStmtAsm.cpp:619:15
  #9 0x82f6310 in clang::Parser::ParseAsmStatement(bool&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseStmtAsm.cpp:682:12
  #10 0x82d15d9 in 
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::AllowedConstructsKind, clang::SourceLocation*, 
clang::Parser::ParsedAttributesWithRange&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseStmt.cpp:277:11
  #11 0x82cfff1 in 
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::AllowedConstructsKind, clang::SourceLocation*) 

[PATCH] D34430: [Clang][TypoCorrection] Clang hangs in typo correction

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

Looks good, but I don't know this code well enough to stamp LGTM. Richard?


Repository:
  rL LLVM

https://reviews.llvm.org/D34430



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34267: do more processing in clang-fuzzer (use EmitAssemblyAction)

[Kostya Serebryany via Phabricator via cfe-commits]

kcc updated this revision to Diff 106573.
kcc added a comment.

Use EmitObjAction; also link and initialize the targets so
that we actually call the optimizer.


https://reviews.llvm.org/D34267

Files:
  tools/clang-fuzzer/CMakeLists.txt
  tools/clang-fuzzer/ClangFuzzer.cpp


Index: tools/clang-fuzzer/ClangFuzzer.cpp
===
--- tools/clang-fuzzer/ClangFuzzer.cpp
+++ tools/clang-fuzzer/ClangFuzzer.cpp
@@ -14,18 +14,25 @@
 
//===--===//
 
 #include "clang/Tooling/Tooling.h"
-#include "clang/Frontend/FrontendActions.h"
+#include "clang/CodeGen/CodeGenAction.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Lex/PreprocessorOptions.h"
 #include "llvm/Option/Option.h"
+#include "llvm/Support/TargetSelect.h"
 
 using namespace clang;
 
 extern "C" int LLVMFuzzerTestOneInput(uint8_t *data, size_t size) {
   std::string s((const char *)data, size);
+  llvm::InitializeAllTargets();
+  llvm::InitializeAllTargetMCs();
+  llvm::InitializeAllAsmPrinters();
+  llvm::InitializeAllAsmParsers();
+
   llvm::opt::ArgStringList CC1Args;
   CC1Args.push_back("-cc1");
   CC1Args.push_back("./test.cc");
+  CC1Args.push_back("-O2");
   llvm::IntrusiveRefCntPtr Files(
   new FileManager(FileSystemOptions()));
   IgnoringDiagConsumer Diags;
@@ -39,7 +46,7 @@
   llvm::MemoryBuffer::getMemBuffer(s);
   Invocation->getPreprocessorOpts().addRemappedFile("./test.cc", 
Input.release());
   std::unique_ptr action(
-  tooling::newFrontendActionFactory());
+  tooling::newFrontendActionFactory());
   std::shared_ptr PCHContainerOps =
   std::make_shared();
   action->runInvocation(std::move(Invocation), Files.get(), PCHContainerOps,
Index: tools/clang-fuzzer/CMakeLists.txt
===
--- tools/clang-fuzzer/CMakeLists.txt
+++ tools/clang-fuzzer/CMakeLists.txt
@@ -1,5 +1,5 @@
 if( LLVM_USE_SANITIZE_COVERAGE )
-  set(LLVM_LINK_COMPONENTS support)
+  set(LLVM_LINK_COMPONENTS ${LLVM_TARGETS_TO_BUILD})
 
   add_clang_executable(clang-fuzzer
 EXCLUDE_FROM_ALL
@@ -10,6 +10,7 @@
 ${CLANG_FORMAT_LIB_DEPS}
 clangAST
 clangBasic
+clangCodeGen
 clangDriver
 clangFrontend
 clangRewriteFrontend


Index: tools/clang-fuzzer/ClangFuzzer.cpp
===
--- tools/clang-fuzzer/ClangFuzzer.cpp
+++ tools/clang-fuzzer/ClangFuzzer.cpp
@@ -14,18 +14,25 @@
 //===--===//
 
 #include "clang/Tooling/Tooling.h"
-#include "clang/Frontend/FrontendActions.h"
+#include "clang/CodeGen/CodeGenAction.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Lex/PreprocessorOptions.h"
 #include "llvm/Option/Option.h"
+#include "llvm/Support/TargetSelect.h"
 
 using namespace clang;
 
 extern "C" int LLVMFuzzerTestOneInput(uint8_t *data, size_t size) {
   std::string s((const char *)data, size);
+  llvm::InitializeAllTargets();
+  llvm::InitializeAllTargetMCs();
+  llvm::InitializeAllAsmPrinters();
+  llvm::InitializeAllAsmParsers();
+
   llvm::opt::ArgStringList CC1Args;
   CC1Args.push_back("-cc1");
   CC1Args.push_back("./test.cc");
+  CC1Args.push_back("-O2");
   llvm::IntrusiveRefCntPtr Files(
   new FileManager(FileSystemOptions()));
   IgnoringDiagConsumer Diags;
@@ -39,7 +46,7 @@
   llvm::MemoryBuffer::getMemBuffer(s);
   Invocation->getPreprocessorOpts().addRemappedFile("./test.cc", Input.release());
   std::unique_ptr action(
-  tooling::newFrontendActionFactory());
+  tooling::newFrontendActionFactory());
   std::shared_ptr PCHContainerOps =
   std::make_shared();
   action->runInvocation(std::move(Invocation), Files.get(), PCHContainerOps,
Index: tools/clang-fuzzer/CMakeLists.txt
===
--- tools/clang-fuzzer/CMakeLists.txt
+++ tools/clang-fuzzer/CMakeLists.txt
@@ -1,5 +1,5 @@
 if( LLVM_USE_SANITIZE_COVERAGE )
-  set(LLVM_LINK_COMPONENTS support)
+  set(LLVM_LINK_COMPONENTS ${LLVM_TARGETS_TO_BUILD})
 
   add_clang_executable(clang-fuzzer
 EXCLUDE_FROM_ALL
@@ -10,6 +10,7 @@
 ${CLANG_FORMAT_LIB_DEPS}
 clangAST
 clangBasic
+clangCodeGen
 clangDriver
 clangFrontend
 clangRewriteFrontend
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34210: Add __has_feature(leak_sanitizer)

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

In https://reviews.llvm.org/D34210#785828, @rnk wrote:

> If LSan is a runtime thing, why not use weak hooks or something to detect 
> LSan at runtime instead of using a macro?


+1

For a run-time-only feature the checking should also be run-time-only (not 
compile-time)


https://reviews.llvm.org/D34210



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34267: do more processing in clang-fuzzer (use EmitAssemblyAction)

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

ignore this for now. I've found how to make it even more interesting (by using 
llvm::InitializeAllTargets, etc), will send an update later.


https://reviews.llvm.org/D34267



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34267: do more processing in clang-fuzzer (use EmitAssemblyAction)

[Kostya Serebryany via Phabricator via cfe-commits]

kcc created this revision.
Herald added a subscriber: mgorny.

use EmitAssemblyAction in clang-fuzzer


https://reviews.llvm.org/D34267

Files:
  tools/clang-fuzzer/CMakeLists.txt
  tools/clang-fuzzer/ClangFuzzer.cpp


Index: tools/clang-fuzzer/ClangFuzzer.cpp
===
--- tools/clang-fuzzer/ClangFuzzer.cpp
+++ tools/clang-fuzzer/ClangFuzzer.cpp
@@ -15,6 +15,7 @@
 
 #include "clang/Tooling/Tooling.h"
 #include "clang/Frontend/FrontendActions.h"
+#include "clang/CodeGen/CodeGenAction.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Lex/PreprocessorOptions.h"
 #include "llvm/Option/Option.h"
@@ -39,7 +40,7 @@
   llvm::MemoryBuffer::getMemBuffer(s);
   Invocation->getPreprocessorOpts().addRemappedFile("./test.cc", 
Input.release());
   std::unique_ptr action(
-  tooling::newFrontendActionFactory());
+  tooling::newFrontendActionFactory());
   std::shared_ptr PCHContainerOps =
   std::make_shared();
   action->runInvocation(std::move(Invocation), Files.get(), PCHContainerOps,
Index: tools/clang-fuzzer/CMakeLists.txt
===
--- tools/clang-fuzzer/CMakeLists.txt
+++ tools/clang-fuzzer/CMakeLists.txt
@@ -9,6 +9,7 @@
   target_link_libraries(clang-fuzzer
 ${CLANG_FORMAT_LIB_DEPS}
 clangAST
+clangCodeGen
 clangBasic
 clangDriver
 clangFrontend


Index: tools/clang-fuzzer/ClangFuzzer.cpp
===
--- tools/clang-fuzzer/ClangFuzzer.cpp
+++ tools/clang-fuzzer/ClangFuzzer.cpp
@@ -15,6 +15,7 @@
 
 #include "clang/Tooling/Tooling.h"
 #include "clang/Frontend/FrontendActions.h"
+#include "clang/CodeGen/CodeGenAction.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Lex/PreprocessorOptions.h"
 #include "llvm/Option/Option.h"
@@ -39,7 +40,7 @@
   llvm::MemoryBuffer::getMemBuffer(s);
   Invocation->getPreprocessorOpts().addRemappedFile("./test.cc", Input.release());
   std::unique_ptr action(
-  tooling::newFrontendActionFactory());
+  tooling::newFrontendActionFactory());
   std::shared_ptr PCHContainerOps =
   std::make_shared();
   action->runInvocation(std::move(Invocation), Files.get(), PCHContainerOps,
Index: tools/clang-fuzzer/CMakeLists.txt
===
--- tools/clang-fuzzer/CMakeLists.txt
+++ tools/clang-fuzzer/CMakeLists.txt
@@ -9,6 +9,7 @@
   target_link_libraries(clang-fuzzer
 ${CLANG_FORMAT_LIB_DEPS}
 clangAST
+clangCodeGen
 clangBasic
 clangDriver
 clangFrontend
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32046: [Preprocessor]Correct Macro-Arg allocation of StringifiedArguments, correct getNumArguments

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

the bots complain about a leak in the new test code. 
Please fix/revert ASAP. 
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/5691/steps/check-clang%20asan/logs/stdio

28905==ERROR: LeakSanitizer: detected memory leaks
==

Direct leak of 216 byte(s) in 1 object(s) allocated from:

  #0 0x4eca08 in __interceptor_malloc 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66
  #1 0xefcb8f in clang::MacroArgs::create(clang::MacroInfo const*, 
llvm::ArrayRef, bool, clang::Preprocessor&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Lex/MacroArgs.cpp:51:27
  #2 0x54dc56 in (anonymous 
namespace)::LexerTest_DontOverallocateStringifyArgs_Test::TestBody() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/unittests/Lex/LexerTest.cpp:405:19
  #3 0x65154e in HandleExceptionsInMethodIfSupported 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2458:12
  #4 0x65154e in testing::Test::Run() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2474
  #5 0x653848 in testing::TestInfo::Run() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
  #6 0x654b86 in testing::TestCase::Run() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
  #7 0x675586 in testing::internal::UnitTestImpl::RunAllTests() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
  #8 0x67487e in 
HandleExceptionsInMethodIfSupported 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2458:12
  #9 0x67487e in testing::UnitTest::Run() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4257
  #10 0x634bfe in RUN_ALL_TESTS 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
  #11 0x634bfe in main 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:51
  #12 0x7f016e9cb82f in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)


Repository:
  rL LLVM

https://reviews.llvm.org/D32046



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34210: Add __has_feature(leak_sanitizer)

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

I'm not sure about this one. 
standalone lsan is a link-time feature only, it doesn't change the compilation, 
so the argument of consistency doesn't apply.


https://reviews.llvm.org/D34210



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33368: [libcxxabi][demangler] Fix a crash in the demangler

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

Done (see 
https://github.com/google/oss-fuzz/blob/master/projects/llvm_libcxxabi/project.yaml)


Repository:
  rL LLVM

https://reviews.llvm.org/D33368



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33368: [libcxxabi][demangler] Fix a crash in the demangler

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

Also, are you now maintaining this code? 
I am trying to find someone who wants to be CC-ed to other demangler bugs 
automatically reported by oss-fuzz.


Repository:
  rL LLVM

https://reviews.llvm.org/D33368



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33368: [libcxxabi][demangler] Fix a crash in the demangler

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

I also encourage you to run the fuzzer on every change in this code.


Repository:
  rL LLVM

https://reviews.llvm.org/D33368



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33368: [libcxxabi][demangler] Fix a crash in the demangler

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

oss-fuzz finds the assertion failure in this new code: 
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=1834


Repository:
  rL LLVM

https://reviews.llvm.org/D33368



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32243: Fix a leak in tools/driver/cc1as_main.cpp

[Kostya Serebryany via Phabricator via cfe-commits]

kcc created this revision.

For some reason, the asan bot has recently started reporting this leak even 
though it existed for ages.


https://reviews.llvm.org/D32243

Files:
  tools/driver/cc1as_main.cpp


Index: tools/driver/cc1as_main.cpp
===
--- tools/driver/cc1as_main.cpp
+++ tools/driver/cc1as_main.cpp
@@ -506,12 +506,12 @@
   // FIXME: Remove this, one day.
   if (!Asm.LLVMArgs.empty()) {
 unsigned NumArgs = Asm.LLVMArgs.size();
-const char **Args = new const char*[NumArgs + 2];
+auto Args = llvm::make_unique(NumArgs + 2);
 Args[0] = "clang (LLVM option parsing)";
 for (unsigned i = 0; i != NumArgs; ++i)
   Args[i + 1] = Asm.LLVMArgs[i].c_str();
 Args[NumArgs + 1] = nullptr;
-llvm::cl::ParseCommandLineOptions(NumArgs + 1, Args);
+llvm::cl::ParseCommandLineOptions(NumArgs + 1, Args.get());
   }
 
   // Execute the invocation, unless there were parsing errors.


Index: tools/driver/cc1as_main.cpp
===
--- tools/driver/cc1as_main.cpp
+++ tools/driver/cc1as_main.cpp
@@ -506,12 +506,12 @@
   // FIXME: Remove this, one day.
   if (!Asm.LLVMArgs.empty()) {
 unsigned NumArgs = Asm.LLVMArgs.size();
-const char **Args = new const char*[NumArgs + 2];
+auto Args = llvm::make_unique(NumArgs + 2);
 Args[0] = "clang (LLVM option parsing)";
 for (unsigned i = 0; i != NumArgs; ++i)
   Args[i + 1] = Asm.LLVMArgs[i].c_str();
 Args[NumArgs + 1] = nullptr;
-llvm::cl::ParseCommandLineOptions(NumArgs + 1, Args);
+llvm::cl::ParseCommandLineOptions(NumArgs + 1, Args.get());
   }
 
   // Execute the invocation, unless there were parsing errors.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29628: [compiler-rt] [test] Enable the strace_test only if strace is installed

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM, 
but please manually verify that the test runs if strace *is* available.


Repository:
  rL LLVM

https://reviews.llvm.org/D29628



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29077: [lsan] Enable LSan for x86 Linux.

[Kostya Serebryany via Phabricator via cfe-commits]

kcc accepted this revision.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rL LLVM

https://reviews.llvm.org/D29077



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28133: add cxa_demangle_fuzzer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc updated this revision to Diff 82571.
kcc added a comment.

remove unneeded  set(LLVM_LINK_COMPONENTS support)


https://reviews.llvm.org/D28133

Files:
  CMakeLists.txt
  fuzz/
  fuzz/CMakeLists.txt
  fuzz/cxa_demangle_fuzzer.cpp


Index: fuzz/cxa_demangle_fuzzer.cpp
===
--- /dev/null
+++ fuzz/cxa_demangle_fuzzer.cpp
@@ -0,0 +1,15 @@
+#include 
+#include 
+#include 
+#include 
+extern "C" char *
+__cxa_demangle(const char *mangled_name, char *buf, size_t *n, int *status);
+
+extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
+  char *str = new char[size+1];
+  memcpy(str, data, size);
+  str[size] = 0;
+  free(__cxa_demangle(str, 0, 0, 0));
+  delete [] str;
+  return 0;
+}
Index: fuzz/CMakeLists.txt
===
--- /dev/null
+++ fuzz/CMakeLists.txt
@@ -0,0 +1,11 @@
+# See http://llvm.org/docs/LibFuzzer.html
+if( LLVM_USE_SANITIZE_COVERAGE )
+  add_executable(cxa_demangle_fuzzer
+cxa_demangle_fuzzer.cpp
+../src/cxa_demangle.cpp
+)
+
+  target_link_libraries(cxa_demangle_fuzzer
+LLVMFuzzer
+)
+endif()
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -432,4 +432,5 @@
   "available!")
 else()
   add_subdirectory(test)
+  add_subdirectory(fuzz)
 endif()


Index: fuzz/cxa_demangle_fuzzer.cpp
===
--- /dev/null
+++ fuzz/cxa_demangle_fuzzer.cpp
@@ -0,0 +1,15 @@
+#include 
+#include 
+#include 
+#include 
+extern "C" char *
+__cxa_demangle(const char *mangled_name, char *buf, size_t *n, int *status);
+
+extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
+  char *str = new char[size+1];
+  memcpy(str, data, size);
+  str[size] = 0;
+  free(__cxa_demangle(str, 0, 0, 0));
+  delete [] str;
+  return 0;
+}
Index: fuzz/CMakeLists.txt
===
--- /dev/null
+++ fuzz/CMakeLists.txt
@@ -0,0 +1,11 @@
+# See http://llvm.org/docs/LibFuzzer.html
+if( LLVM_USE_SANITIZE_COVERAGE )
+  add_executable(cxa_demangle_fuzzer
+cxa_demangle_fuzzer.cpp
+../src/cxa_demangle.cpp
+)
+
+  target_link_libraries(cxa_demangle_fuzzer
+LLVMFuzzer
+)
+endif()
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -432,4 +432,5 @@
   "available!")
 else()
   add_subdirectory(test)
+  add_subdirectory(fuzz)
 endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28133: add cxa_demangle_fuzzer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc marked an inline comment as done.
kcc added a comment.

yes, removed.


https://reviews.llvm.org/D28133



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28133: add cxa_demangle_fuzzer

[Kostya Serebryany via Phabricator via cfe-commits]

kcc created this revision.
kcc added reviewers: compnerd, mehdi_amini, mclow.lists.
kcc added a subscriber: cfe-commits.
Herald added a subscriber: mgorny.

All easy-to-find bugs in cxa_demangle where fixed now
(https://bugs.chromium.org/p/chromium/issues/detail?id=606626)
except for one (https://llvm.org/bugs/show_bug.cgi?id=31031).
Now I'd like to properly integrate this fuzzer with the source tree
and then run the fuzzer continuously on https://github.com/google/oss-fuzz


https://reviews.llvm.org/D28133

Files:
  CMakeLists.txt
  fuzz/
  fuzz/CMakeLists.txt
  fuzz/cxa_demangle_fuzzer.cpp


Index: fuzz/cxa_demangle_fuzzer.cpp
===
--- /dev/null
+++ fuzz/cxa_demangle_fuzzer.cpp
@@ -0,0 +1,15 @@
+#include 
+#include 
+#include 
+#include 
+extern "C" char *
+__cxa_demangle(const char *mangled_name, char *buf, size_t *n, int *status);
+
+extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
+  char *str = new char[size+1];
+  memcpy(str, data, size);
+  str[size] = 0;
+  free(__cxa_demangle(str, 0, 0, 0));
+  delete [] str;
+  return 0;
+}
Index: fuzz/CMakeLists.txt
===
--- /dev/null
+++ fuzz/CMakeLists.txt
@@ -0,0 +1,13 @@
+# See http://llvm.org/docs/LibFuzzer.html
+if( LLVM_USE_SANITIZE_COVERAGE )
+  set(LLVM_LINK_COMPONENTS support)
+
+  add_executable(cxa_demangle_fuzzer
+cxa_demangle_fuzzer.cpp
+../src/cxa_demangle.cpp
+)
+
+  target_link_libraries(cxa_demangle_fuzzer
+LLVMFuzzer
+)
+endif()
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -432,4 +432,5 @@
   "available!")
 else()
   add_subdirectory(test)
+  add_subdirectory(fuzz)
 endif()


Index: fuzz/cxa_demangle_fuzzer.cpp
===
--- /dev/null
+++ fuzz/cxa_demangle_fuzzer.cpp
@@ -0,0 +1,15 @@
+#include 
+#include 
+#include 
+#include 
+extern "C" char *
+__cxa_demangle(const char *mangled_name, char *buf, size_t *n, int *status);
+
+extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
+  char *str = new char[size+1];
+  memcpy(str, data, size);
+  str[size] = 0;
+  free(__cxa_demangle(str, 0, 0, 0));
+  delete [] str;
+  return 0;
+}
Index: fuzz/CMakeLists.txt
===
--- /dev/null
+++ fuzz/CMakeLists.txt
@@ -0,0 +1,13 @@
+# See http://llvm.org/docs/LibFuzzer.html
+if( LLVM_USE_SANITIZE_COVERAGE )
+  set(LLVM_LINK_COMPONENTS support)
+
+  add_executable(cxa_demangle_fuzzer
+cxa_demangle_fuzzer.cpp
+../src/cxa_demangle.cpp
+)
+
+  target_link_libraries(cxa_demangle_fuzzer
+LLVMFuzzer
+)
+endif()
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -432,4 +432,5 @@
   "available!")
 else()
   add_subdirectory(test)
+  add_subdirectory(fuzz)
 endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D27316: [CUDA] Filter out dirver sanitizer args for NVPTX

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

I am not sure this is going to work. 
You essentially break on the first iteration in the beginning of the loop. 
Why not exit the function before the loop? 
Also, the loop "claims" the args and by breaking early you leave the args 
unclaimed.

I don't remember this code well enough to argue about it w/o tests. :(


https://reviews.llvm.org/D27316



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D27316: [CUDA] Filter out dirver sanitizer args for NVPTX

[Kostya Serebryany via Phabricator via cfe-commits]

kcc added a comment.

at the very least this requires a test... Let me thing about the logic a bit 
more...


https://reviews.llvm.org/D27316



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits