r304631 - [sanitizer-coverage] one more flavor of coverage: -fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. (clang part)

2017-06-02 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Fri Jun  2 20:36:23 2017
New Revision: 304631

URL: http://llvm.org/viewvc/llvm-project?rev=304631&view=rev
Log:
[sanitizer-coverage] one more flavor of coverage: 
-fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting 
yet. (clang part)

Modified:
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=304631&r1=304630&r2=304631&view=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Fri Jun  2 20:36:23 2017
@@ -293,6 +293,9 @@ def fsanitize_coverage_trace_gep
 def fsanitize_coverage_8bit_counters
 : Flag<["-"], "fsanitize-coverage-8bit-counters">,
   HelpText<"Enable frequency counters in sanitizer coverage">;
+def fsanitize_coverage_inline_8bit_counters
+: Flag<["-"], "fsanitize-coverage-inline-8bit-counters">,
+  HelpText<"Enable inline 8-bit counters in sanitizer coverage">;
 def fsanitize_coverage_trace_pc
 : Flag<["-"], "fsanitize-coverage-trace-pc">,
   HelpText<"Enable PC tracing in sanitizer coverage">;

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=304631&r1=304630&r2=304631&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Fri Jun  2 20:36:23 2017
@@ -163,6 +163,7 @@ CODEGENOPT(SanitizeCoverageTracePC, 1, 0
   ///< in sanitizer coverage.
 CODEGENOPT(SanitizeCoverageTracePCGuard, 1, 0) ///< Enable PC tracing with 
guard
///< in sanitizer coverage.
+CODEGENOPT(SanitizeCoverageInline8bitCounters, 1, 0) ///< Use inline 8bit 
counters.
 CODEGENOPT(SanitizeCoverageNoPrune, 1, 0) ///< Disable coverage pruning.
 CODEGENOPT(SanitizeStats , 1, 0) ///< Collect statistics for sanitizers.
 CODEGENOPT(SimplifyLibCalls  , 1, 1) ///< Set when -fbuiltin is enabled.

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=304631&r1=304630&r2=304631&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Fri Jun  2 20:36:23 2017
@@ -187,6 +187,7 @@ static void addSanitizerCoveragePass(con
   Opts.TracePC = CGOpts.SanitizeCoverageTracePC;
   Opts.TracePCGuard = CGOpts.SanitizeCoverageTracePCGuard;
   Opts.NoPrune = CGOpts.SanitizeCoverageNoPrune;
+  Opts.Inline8bitCounters = CGOpts.SanitizeCoverageInline8bitCounters;
   PM.add(createSanitizerCoverageModulePass(Opts));
 }
 

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=304631&r1=304630&r2=304631&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Fri Jun  2 20:36:23 2017
@@ -48,13 +48,14 @@ enum CoverageFeature {
   CoverageBB = 1 << 1,
   CoverageEdge = 1 << 2,
   CoverageIndirCall = 1 << 3,
-  CoverageTraceBB = 1 << 4,
+  CoverageTraceBB = 1 << 4,  // Deprecated.
   CoverageTraceCmp = 1 << 5,
   CoverageTraceDiv = 1 << 6,
   CoverageTraceGep = 1 << 7,
-  Coverage8bitCounters = 1 << 8,
+  Coverage8bitCounters = 1 << 8,  // Deprecated.
   CoverageTracePC = 1 << 9,
   CoverageTracePCGuard = 1 << 10,
+  CoverageInline8bitCounters = 1 << 12,
   CoverageNoPrune = 1 << 11,
 };
 
@@ -530,7 +531,8 @@ SanitizerArgs::SanitizerArgs(const ToolC
   }
 
   // trace-pc w/o func/bb/edge implies edge.
-  if ((CoverageFeatures & (CoverageTracePC | CoverageTracePCGuard)) &&
+  if ((CoverageFeatures &
+   (CoverageTracePC | CoverageTracePCGuard | CoverageInline8bitCounters)) 
&&
   !(CoverageFeatures & InsertionPointTypes))
 CoverageFeatures |= CoverageEdge;
 
@@ -637,6 +639,7 @@ void SanitizerArgs::addArgs(const ToolCh
 std::make_pair(Coverage8bitCounters, "-fsanitize-coverage-8bit-counters"),
 std::make_pair(CoverageTracePC, "-fsanitize-coverage-trace-pc"),
 std::make_pair(CoverageTracePCGuard, "-fsanitize-coverage-trace-pc-guard"),
+std::make_pair(CoverageInline8bitCounters, 
"-fsanitize-coverage-inline-8bit-counters"),
 std::make_pair(CoverageNoPrune, "-fsanitize-coverage-no-prune")};
   for (a

Re: r304697 - Revert "[sanitizer-coverage] one more flavor of coverage: -fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. (clang part)"

2017-06-08 Thread Kostya Serebryany via cfe-commits
How did it break it?
Any logs?

On Mon, Jun 5, 2017 at 12:35 AM, Renato Golin via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rengolin
> Date: Mon Jun  5 02:35:45 2017
> New Revision: 304697
>
> URL: http://llvm.org/viewvc/llvm-project?rev=304697&view=rev
> Log:
> Revert "[sanitizer-coverage] one more flavor of coverage:
> -fsanitize-coverage=inline-8bit-counters. Experimental so far, not
> documenting yet. (clang part)"
>
> This reverts commit r304631, as it broke ARM/AArch64 bots for 2 days.
>
> Modified:
> cfe/trunk/include/clang/Driver/CC1Options.td
> cfe/trunk/include/clang/Frontend/CodeGenOptions.def
> cfe/trunk/lib/CodeGen/BackendUtil.cpp
> cfe/trunk/lib/Driver/SanitizerArgs.cpp
> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> cfe/trunk/test/Driver/fsanitize-coverage.c
>
> Modified: cfe/trunk/include/clang/Driver/CC1Options.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Driver/CC1Options.td?rev=304697&r1=304696&r2=304697&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Driver/CC1Options.td (original)
> +++ cfe/trunk/include/clang/Driver/CC1Options.td Mon Jun  5 02:35:45 2017
> @@ -293,9 +293,6 @@ def fsanitize_coverage_trace_gep
>  def fsanitize_coverage_8bit_counters
>  : Flag<["-"], "fsanitize-coverage-8bit-counters">,
>HelpText<"Enable frequency counters in sanitizer coverage">;
> -def fsanitize_coverage_inline_8bit_counters
> -: Flag<["-"], "fsanitize-coverage-inline-8bit-counters">,
> -  HelpText<"Enable inline 8-bit counters in sanitizer coverage">;
>  def fsanitize_coverage_trace_pc
>  : Flag<["-"], "fsanitize-coverage-trace-pc">,
>HelpText<"Enable PC tracing in sanitizer coverage">;
>
> Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Frontend/CodeGenOptions.def?rev=304697&r1=304696&r2=304697&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
> +++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Mon Jun  5
> 02:35:45 2017
> @@ -163,7 +163,6 @@ CODEGENOPT(SanitizeCoverageTracePC, 1, 0
>///< in sanitizer coverage.
>  CODEGENOPT(SanitizeCoverageTracePCGuard, 1, 0) ///< Enable PC tracing
> with guard
> ///< in sanitizer coverage.
> -CODEGENOPT(SanitizeCoverageInline8bitCounters, 1, 0) ///< Use inline
> 8bit counters.
>  CODEGENOPT(SanitizeCoverageNoPrune, 1, 0) ///< Disable coverage pruning.
>  CODEGENOPT(SanitizeStats , 1, 0) ///< Collect statistics for
> sanitizers.
>  CODEGENOPT(SimplifyLibCalls  , 1, 1) ///< Set when -fbuiltin is enabled.
>
> Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> BackendUtil.cpp?rev=304697&r1=304696&r2=304697&view=diff
> 
> ==
> --- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
> +++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon Jun  5 02:35:45 2017
> @@ -187,7 +187,6 @@ static void addSanitizerCoveragePass(con
>Opts.TracePC = CGOpts.SanitizeCoverageTracePC;
>Opts.TracePCGuard = CGOpts.SanitizeCoverageTracePCGuard;
>Opts.NoPrune = CGOpts.SanitizeCoverageNoPrune;
> -  Opts.Inline8bitCounters = CGOpts.SanitizeCoverageInline8bitCounters;
>PM.add(createSanitizerCoverageModulePass(Opts));
>  }
>
>
> Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/
> SanitizerArgs.cpp?rev=304697&r1=304696&r2=304697&view=diff
> 
> ==
> --- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
> +++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Mon Jun  5 02:35:45 2017
> @@ -48,14 +48,13 @@ enum CoverageFeature {
>CoverageBB = 1 << 1,
>CoverageEdge = 1 << 2,
>CoverageIndirCall = 1 << 3,
> -  CoverageTraceBB = 1 << 4,  // Deprecated.
> +  CoverageTraceBB = 1 << 4,
>CoverageTraceCmp = 1 << 5,
>CoverageTraceDiv = 1 << 6,
>CoverageTraceGep = 1 << 7,
> -  Coverage8bitCounters = 1 << 8,  // Deprecated.
> +  Coverage8bitCounters = 1 << 8,
>CoverageTracePC = 1 << 9,
>CoverageTracePCGuard = 1 << 10,
> -  CoverageInline8bitCounters = 1 << 12,
>CoverageNoPrune = 1 << 11,
>  };
>
> @@ -531,8 +530,7 @@ SanitizerArgs::SanitizerArgs(const ToolC
>}
>
>// trace-pc w/o func/bb/edge implies edge.
> -  if ((CoverageFeatures &
> -   (CoverageTracePC | CoverageTracePCGuard |
> CoverageInline8bitCounters)) &&
> +  if ((CoverageFeatures & (CoverageTracePC | CoverageTracePCGuard)) &&
>!(CoverageFeatures & InsertionPointTypes))
>  CoverageFeatures |= CoverageEdge;
>
> @@ -639,7 +637,6 @@ void SanitizerArgs::addAr

Re: r304697 - Revert "[sanitizer-coverage] one more flavor of coverage: -fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. (clang part)"

2017-06-08 Thread Kostya Serebryany via cfe-commits
Ah, I see https://bugs.llvm.org/show_bug.cgi?id=33308, moving the
discussion there.

On Thu, Jun 8, 2017 at 10:05 AM, Kostya Serebryany  wrote:

> How did it break it?
> Any logs?
>
> On Mon, Jun 5, 2017 at 12:35 AM, Renato Golin via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rengolin
>> Date: Mon Jun  5 02:35:45 2017
>> New Revision: 304697
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=304697&view=rev
>> Log:
>> Revert "[sanitizer-coverage] one more flavor of coverage:
>> -fsanitize-coverage=inline-8bit-counters. Experimental so far, not
>> documenting yet. (clang part)"
>>
>> This reverts commit r304631, as it broke ARM/AArch64 bots for 2 days.
>>
>> Modified:
>> cfe/trunk/include/clang/Driver/CC1Options.td
>> cfe/trunk/include/clang/Frontend/CodeGenOptions.def
>> cfe/trunk/lib/CodeGen/BackendUtil.cpp
>> cfe/trunk/lib/Driver/SanitizerArgs.cpp
>> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>> cfe/trunk/test/Driver/fsanitize-coverage.c
>>
>> Modified: cfe/trunk/include/clang/Driver/CC1Options.td
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Driver/CC1Options.td?rev=304697&r1=304696&r2=304697&view=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Driver/CC1Options.td (original)
>> +++ cfe/trunk/include/clang/Driver/CC1Options.td Mon Jun  5 02:35:45 2017
>> @@ -293,9 +293,6 @@ def fsanitize_coverage_trace_gep
>>  def fsanitize_coverage_8bit_counters
>>  : Flag<["-"], "fsanitize-coverage-8bit-counters">,
>>HelpText<"Enable frequency counters in sanitizer coverage">;
>> -def fsanitize_coverage_inline_8bit_counters
>> -: Flag<["-"], "fsanitize-coverage-inline-8bit-counters">,
>> -  HelpText<"Enable inline 8-bit counters in sanitizer coverage">;
>>  def fsanitize_coverage_trace_pc
>>  : Flag<["-"], "fsanitize-coverage-trace-pc">,
>>HelpText<"Enable PC tracing in sanitizer coverage">;
>>
>> Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Frontend/CodeGenOptions.def?rev=304697&r1=304696&r2=304697&view=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
>> +++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Mon Jun  5
>> 02:35:45 2017
>> @@ -163,7 +163,6 @@ CODEGENOPT(SanitizeCoverageTracePC, 1, 0
>>///< in sanitizer coverage.
>>  CODEGENOPT(SanitizeCoverageTracePCGuard, 1, 0) ///< Enable PC tracing
>> with guard
>> ///< in sanitizer
>> coverage.
>> -CODEGENOPT(SanitizeCoverageInline8bitCounters, 1, 0) ///< Use inline
>> 8bit counters.
>>  CODEGENOPT(SanitizeCoverageNoPrune, 1, 0) ///< Disable coverage pruning.
>>  CODEGENOPT(SanitizeStats , 1, 0) ///< Collect statistics for
>> sanitizers.
>>  CODEGENOPT(SimplifyLibCalls  , 1, 1) ///< Set when -fbuiltin is enabled.
>>
>> Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/Ba
>> ckendUtil.cpp?rev=304697&r1=304696&r2=304697&view=diff
>> 
>> ==
>> --- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon Jun  5 02:35:45 2017
>> @@ -187,7 +187,6 @@ static void addSanitizerCoveragePass(con
>>Opts.TracePC = CGOpts.SanitizeCoverageTracePC;
>>Opts.TracePCGuard = CGOpts.SanitizeCoverageTracePCGuard;
>>Opts.NoPrune = CGOpts.SanitizeCoverageNoPrune;
>> -  Opts.Inline8bitCounters = CGOpts.SanitizeCoverageInline8bitCounters;
>>PM.add(createSanitizerCoverageModulePass(Opts));
>>  }
>>
>>
>> Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/San
>> itizerArgs.cpp?rev=304697&r1=304696&r2=304697&view=diff
>> 
>> ==
>> --- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
>> +++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Mon Jun  5 02:35:45 2017
>> @@ -48,14 +48,13 @@ enum CoverageFeature {
>>CoverageBB = 1 << 1,
>>CoverageEdge = 1 << 2,
>>CoverageIndirCall = 1 << 3,
>> -  CoverageTraceBB = 1 << 4,  // Deprecated.
>> +  CoverageTraceBB = 1 << 4,
>>CoverageTraceCmp = 1 << 5,
>>CoverageTraceDiv = 1 << 6,
>>CoverageTraceGep = 1 << 7,
>> -  Coverage8bitCounters = 1 << 8,  // Deprecated.
>> +  Coverage8bitCounters = 1 << 8,
>>CoverageTracePC = 1 << 9,
>>CoverageTracePCGuard = 1 << 10,
>> -  CoverageInline8bitCounters = 1 << 12,
>>CoverageNoPrune = 1 << 11,
>>  };
>>
>> @@ -531,8 +530,7 @@ SanitizerArgs::SanitizerArgs(const ToolC
>>}
>>
>>// trace-pc w/o func/bb/edge implies edge.
>> -  if ((CoverageFeatures &
>> -   (CoverageTracePC | CoverageTra

Re: r305022 - [ASTMatchers] Add clang-query support for equals matcher

2017-06-08 Thread Kostya Serebryany via cfe-commits
The test seems to be failing:
llvm/tools/clang/unittests/ASTMatchers/Dynamic/RegistryTest.cpp:533: Failure
Value of: matches("double x = 1.2f;", DoubleStmt)
  Actual: false (Could not find match in "double x = 1.2f;")
Expected: true


On Thu, Jun 8, 2017 at 3:00 PM, Peter Wu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: lekensteyn
> Date: Thu Jun  8 17:00:58 2017
> New Revision: 305022
>
> URL: http://llvm.org/viewvc/llvm-project?rev=305022&view=rev
> Log:
> [ASTMatchers] Add clang-query support for equals matcher
>
> Summary:
> This allows the clang-query tool to use matchers like
> "integerLiteral(equals(32))". For this to work, an overloaded function
> is added for each possible parameter type.
>
> Reviewed By: aaron.ballman
>
> Differential Revision: https://reviews.llvm.org/D33094
>
> Modified:
> cfe/trunk/docs/LibASTMatchersReference.html
> cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
> cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
> cfe/trunk/unittests/ASTMatchers/Dynamic/RegistryTest.cpp
>
> Modified: cfe/trunk/docs/LibASTMatchersReference.html
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/
> LibASTMatchersReference.html?rev=305022&r1=305021&r2=305022&view=diff
> 
> ==
> --- cfe/trunk/docs/LibASTMatchersReference.html (original)
> +++ cfe/trunk/docs/LibASTMatchersReference.html Thu Jun  8 17:00:58 2017
> @@ -1859,17 +1859,36 @@ Example matches a || b (matcher = binary
>  
>
>
> -Matcher onclick="toggle('equals2')">equalsValueT
> Value
> -Matches literals that
> are equal to the given value.
> +Matcher 1CXXBoolLiteralExpr.html">CXXBoolLiteralExpr> onclick="toggle('equals2')">equalsValueT
> Value
> +Matches literals that
> are equal to the given value of type ValueT.
>
> -Example matches true (matcher = cxxBoolLiteral(equals(true)))
> -  true
> +Given
> +  f('false, 3.14, 42);
> +characterLiteral(equals(0))
> +  matches 'cxxBoolLiteral(equals(false)) and cxxBoolLiteral(equals(0))
> +  match false
> +floatLiteral(equals(3.14)) and floatLiteral(equals(314e-2))
> +  match 3.14
> +integerLiteral(equals(42))
> +  matches 42
>
> -Usable as: Matcher doxygen/classclang_1_1CharacterLiteral.html">CharacterLiteral>,
> Matcher,
> +Usable as: Matcher doxygen/classclang_1_1CharacterLiteral.html">CharacterLiteral>,
> Matcher 1CXXBoolLiteralExpr.html">CXXBoolLiteralExpr>,
> Matcher doxygen/classclang_1_1FloatingLiteral.html">FloatingLiteral>,
> Matcher 1IntegerLiteral.html">IntegerLiteral>
>  
>
>
> +Matcher 1CXXBoolLiteralExpr.html">CXXBoolLiteralExpr> onclick="toggle('equals5')">equalsbool
> Value
> +
> +
> +
> +Matcher 1CXXBoolLiteralExpr.html">CXXBoolLiteralExpr> onclick="toggle('equals11')"> name="equals11Anchor">equalsdouble
> Value
> +
> +
> +
> +Matcher 1CXXBoolLiteralExpr.html">CXXBoolLiteralExpr> onclick="toggle('equals8')"> name="equals8Anchor">equalsunsigned
> Value
> +
> +
> +
>  Matcher 1CXXCatchStmt.html">CXXCatchStmt> onclick="toggle('isCatchAll0')">
> isCatchAll
>  Matches a C++ catch
> statement that has a catch-all handler.
>
> @@ -2296,16 +2315,35 @@ Example: matches the implicit cast aroun
>
>
>  Matcher 1CharacterLiteral.html">CharacterLiteral> onclick="toggle('equals3')">equalsValueT
> Value
> -Matches literals that
> are equal to the given value.
> +Matches literals that
> are equal to the given value of type ValueT.
>
> -Example matches true (matcher = cxxBoolLiteral(equals(true)))
> -  true
> +Given
> +  f('false, 3.14, 42);
> +characterLiteral(equals(0))
> +  matches 'cxxBoolLiteral(equals(false)) and cxxBoolLiteral(equals(0))
> +  match false
> +floatLiteral(equals(3.14)) and floatLiteral(equals(314e-2))
> +  match 3.14
> +integerLiteral(equals(42))
> +  matches 42
>
> -Usable as: Matcher doxygen/classclang_1_1CharacterLiteral.html">CharacterLiteral>,
> Matcher,
> +Usable as: Matcher doxygen/classclang_1_1CharacterLiteral.html">CharacterLiteral>,
> Matcher 1CXXBoolLiteralExpr.html">CXXBoolLiteralExpr>,
> Matcher doxygen/classclang_1_1FloatingLiteral.html">FloatingLiteral>,
> Matcher 1IntegerLiteral.html">IntegerLiteral>
>  
>
>
> +Matcher 1CharacterLiteral.html">CharacterLiteral> onclick="toggle('equals4')">equalsbool
> Value
> +
> +
> +
> +Matcher<

r305026 - [sanitizer-coverage] one more flavor of coverage: -fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. Reapplying revisions 304630, 304631, 304632, 304673, see

2017-06-08 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Thu Jun  8 17:58:19 2017
New Revision: 305026

URL: http://llvm.org/viewvc/llvm-project?rev=305026&view=rev
Log:
[sanitizer-coverage] one more flavor of coverage: 
-fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting 
yet. Reapplying revisions 304630, 304631, 304632, 304673, see PR33308 

Modified:
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=305026&r1=305025&r2=305026&view=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Thu Jun  8 17:58:19 2017
@@ -293,6 +293,9 @@ def fsanitize_coverage_trace_gep
 def fsanitize_coverage_8bit_counters
 : Flag<["-"], "fsanitize-coverage-8bit-counters">,
   HelpText<"Enable frequency counters in sanitizer coverage">;
+def fsanitize_coverage_inline_8bit_counters
+: Flag<["-"], "fsanitize-coverage-inline-8bit-counters">,
+  HelpText<"Enable inline 8-bit counters in sanitizer coverage">;
 def fsanitize_coverage_trace_pc
 : Flag<["-"], "fsanitize-coverage-trace-pc">,
   HelpText<"Enable PC tracing in sanitizer coverage">;

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=305026&r1=305025&r2=305026&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Thu Jun  8 17:58:19 2017
@@ -163,6 +163,7 @@ CODEGENOPT(SanitizeCoverageTracePC, 1, 0
   ///< in sanitizer coverage.
 CODEGENOPT(SanitizeCoverageTracePCGuard, 1, 0) ///< Enable PC tracing with 
guard
///< in sanitizer coverage.
+CODEGENOPT(SanitizeCoverageInline8bitCounters, 1, 0) ///< Use inline 8bit 
counters.
 CODEGENOPT(SanitizeCoverageNoPrune, 1, 0) ///< Disable coverage pruning.
 CODEGENOPT(SanitizeStats , 1, 0) ///< Collect statistics for sanitizers.
 CODEGENOPT(SimplifyLibCalls  , 1, 1) ///< Set when -fbuiltin is enabled.

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=305026&r1=305025&r2=305026&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Thu Jun  8 17:58:19 2017
@@ -187,6 +187,7 @@ static void addSanitizerCoveragePass(con
   Opts.TracePC = CGOpts.SanitizeCoverageTracePC;
   Opts.TracePCGuard = CGOpts.SanitizeCoverageTracePCGuard;
   Opts.NoPrune = CGOpts.SanitizeCoverageNoPrune;
+  Opts.Inline8bitCounters = CGOpts.SanitizeCoverageInline8bitCounters;
   PM.add(createSanitizerCoverageModulePass(Opts));
 }
 

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=305026&r1=305025&r2=305026&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Thu Jun  8 17:58:19 2017
@@ -48,13 +48,14 @@ enum CoverageFeature {
   CoverageBB = 1 << 1,
   CoverageEdge = 1 << 2,
   CoverageIndirCall = 1 << 3,
-  CoverageTraceBB = 1 << 4,
+  CoverageTraceBB = 1 << 4,  // Deprecated.
   CoverageTraceCmp = 1 << 5,
   CoverageTraceDiv = 1 << 6,
   CoverageTraceGep = 1 << 7,
-  Coverage8bitCounters = 1 << 8,
+  Coverage8bitCounters = 1 << 8,  // Deprecated.
   CoverageTracePC = 1 << 9,
   CoverageTracePCGuard = 1 << 10,
+  CoverageInline8bitCounters = 1 << 12,
   CoverageNoPrune = 1 << 11,
 };
 
@@ -530,7 +531,8 @@ SanitizerArgs::SanitizerArgs(const ToolC
   }
 
   // trace-pc w/o func/bb/edge implies edge.
-  if ((CoverageFeatures & (CoverageTracePC | CoverageTracePCGuard)) &&
+  if ((CoverageFeatures &
+   (CoverageTracePC | CoverageTracePCGuard | CoverageInline8bitCounters)) 
&&
   !(CoverageFeatures & InsertionPointTypes))
 CoverageFeatures |= CoverageEdge;
 
@@ -637,6 +639,7 @@ void SanitizerArgs::addArgs(const ToolCh
 std::make_pair(Coverage8bitCounters, "-fsanitize-coverage-8bit-counters"),
 std::make_pair(CoverageTracePC, "-fsanitize-coverage-trace-pc"),
 std::make_pair(CoverageTracePCGuard, "-fsanitize-coverage-trace-pc-guard"),
+std::make_pair(CoverageInline8bitCounters, 
"-fsanitize-coverage-inline-8bit-counters"),
 std::make_pair(Coverag

Re: r305425 - [Preprocessor]Correct Macro-Arg allocation of StringifiedArguments,

2017-06-15 Thread Kostya Serebryany via cfe-commits
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)



On Wed, Jun 14, 2017 at 4:09 PM, Erich Keane via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: erichkeane
> Date: Wed Jun 14 18:09:01 2017
> New Revision: 305425
>
> URL: http://llvm.org/viewvc/llvm-project?rev=305425&view=rev
> Log:
> [Preprocessor]Correct Macro-Arg allocation of StringifiedArguments,
> correct getNumArguments
>
> StringifiedArguments is allocated (resized) based on the size the
> getNumArguments function. However, this function ACTUALLY currently
> returns the amount of total UnexpArgTokens which is minimum the same as
> the new implementation of getNumMacroArguments, since empty/omitted
> arguments
> result in 1 UnexpArgToken, and included ones at minimum include 2
> (1 for the arg itself, 1 for eof).
>
> This patch renames the otherwise unused getNumArguments to be more clear
> that it is the number of arguments that the Macro expects, and thus the
> maximum
> number that can be stringified. This patch also replaces the explicit
> memset
> (which results in value instantiation of the new tokens, PLUS clearing the
> memory) with brace initialization.
>
> Differential Revision: https://reviews.llvm.org/D32046
>
> Modified:
> cfe/trunk/include/clang/Lex/MacroArgs.h
> cfe/trunk/lib/Lex/MacroArgs.cpp
> cfe/trunk/unittests/Lex/LexerTest.cpp
>
> Modified: cfe/trunk/include/clang/Lex/MacroArgs.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Lex/MacroArgs.h?rev=305425&r1=305424&r2=305425&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Lex/MacroArgs.h (original)
> +++ cfe/trunk/include/clang/Lex/MacroArgs.h Wed Jun 14 18:09:01 2017
> @@ -53,9 +53,12 @@ class MacroArgs {
>/// Preprocessor owns which we use to avoid thrashing malloc/free.
>MacroArgs *ArgCache;
>
> -  MacroArgs(unsigned NumToks, bool varargsElided)
> -: NumUnexpArgTokens(NumToks), VarargsElided(varargsElided),
> -  ArgCache(nullptr) {}
> +  /// MacroArgs - The number of arguments the invoked macro expects.
> +  unsigned NumMacroArgs;
> +
> +  MacroArgs(unsigned NumToks, bool varargsElided, unsigned MacroArgs)
> +  : NumUnexpArgTokens(NumToks), VarargsElided(varargsElided),
> +ArgCache(nullptr), NumMacroArgs(MacroArgs) {}
>~MacroArgs() = default;
>
>  public:
> @@ -94,10 +97,9 @@ public:
>SourceLocation ExpansionLocStart,
>SourceLocation ExpansionLocEnd);
>
> -  /// getNumArguments - Return the number of arguments passed into this
> macro
> 

Re: Status of CET support? (Re: [PATCH] D40224:...)

2017-12-14 Thread Kostya Serebryany via cfe-commits
On Thu, Dec 14, 2017 at 2:39 AM, Pavel Chupin 
wrote:

> Hi Kostya,
> Long time no see. :)
>

Yey!! Thanks for the update!

--kcc


> I would estimate that everything (glibc, kernel, loader, simulator)
> should be available approx. February 2018 as soon as implementation
> finished and tested on our side.
> CET is enabled already in GCC, glibc branch with CET is available
> (https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/
> heads/hjl/cet/master)
> and will be upstreamed as soon as kernel upstream progress made.
>
> On Wed, Nov 29, 2017 at 8:41 AM, Ben Simhon, Oren
>  wrote:
> > Hi Kostya,
> >
> >
> >
> > Sorry for the detailed response.
> >
> > I forwarded your questions to GCC team who are also adding CET support
> for
> > Glibc / Linux Kernel / Loader.
> >
> >
> >
> > I also talked to the simulations team to understand their timeline.
> >
> > They will contact this mailing list with detailed answers.
> >
> >
> >
> > There are few more patches to complete LLVM Compiler support.
> >
> > I will appreciate your help in reviewing some of them:
> >
> > https://reviews.llvm.org/D40482
> >
> > https://reviews.llvm.org/D40478
> >
> >
> >
> > Thanks,
> >
> > Oren
> >
> >
> >
> > From: Kostya Serebryany [mailto:k...@google.com]
> > Sent: Tuesday, November 28, 2017 01:46
> > Cc: Ben Simhon, Oren ;
> pavel.v.chu...@gmail.com;
> > Keane, Erich ; Justin Bogner <
> m...@justinbogner.com>;
> > ablik...@gmail.com; Reid Kleckner ; Craig Topper
> > ; cfe-commits ;
> Evgeniy
> > Stepanov ; Peter Collingbourne ;
> Sahita,
> > Ravi ; Zuckerman, Michael
> > 
> > Subject: Status of CET support? (Re: [PATCH] D40224:...)
> >
> >
> >
> > Hi,
> >
> >
> >
> > I see these patches for the CET support in LLVM -- great!
> >
> > Could you please also tell us
> >
> >   * what's the status of the Linux Kernel and Glibc support for CET?
> >
> >   * how we can start evaluating the hardware feature (simulators, etc)?
> >
> >
> >
> > Thanks!
> >
> >
> >
> > --kcc
> >
> >
> >
> >
> >
> > On Sun, Nov 26, 2017 at 4:35 AM, Phabricator via Phabricator via
> cfe-commits
> >  wrote:
> >
> > This revision was automatically updated to reflect the committed changes.
> > Closed by commit rL318995: Control-Flow Enforcement Technology - Shadow
> > Stack and Indirect Branch Tracking… (authored by orenb).
> >
> > Changed prior to commit:
> >   https://reviews.llvm.org/D40224?vs=123937&id=124287#toc
> >
> > Repository:
> >   rL LLVM
> >
> > https://reviews.llvm.org/D40224
> >
> > Files:
> >   cfe/trunk/include/clang/Basic/BuiltinsX86.def
> >   cfe/trunk/include/clang/Basic/BuiltinsX86_64.def
> >   cfe/trunk/include/clang/Driver/Options.td
> >   cfe/trunk/lib/Basic/Targets/X86.cpp
> >   cfe/trunk/lib/Basic/Targets/X86.h
> >   cfe/trunk/lib/Headers/CMakeLists.txt
> >   cfe/trunk/lib/Headers/cetintrin.h
> >   cfe/trunk/lib/Headers/immintrin.h
> >   cfe/trunk/test/CodeGen/builtins-x86.c
> >   cfe/trunk/test/CodeGen/cetintrin.c
> >   cfe/trunk/test/Driver/x86-target-features.c
> >   cfe/trunk/test/Preprocessor/x86_target_features.c
> >
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >
> >
> >
> > -
> > Intel Israel (74) Limited
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
>
>
>
> --
> Pavel Chupin
> Intel Corporation
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r321027 - [hwasan] update the design doc

2017-12-18 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Mon Dec 18 13:40:07 2017
New Revision: 321027

URL: http://llvm.org/viewvc/llvm-project?rev=321027&view=rev
Log:
[hwasan] update the design doc

Modified:
cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst

Modified: cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst?rev=321027&r1=321026&r2=321027&view=diff
==
--- cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst (original)
+++ cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst Mon Dec 18 
13:40:07 2017
@@ -21,7 +21,7 @@ The redzones, the quarantine, and, to a
 sources of AddressSanitizer's memory overhead.
 See the `AddressSanitizer paper`_ for details.
 
-AArch64 has the `Address Tagging`_, a hardware feature that allows
+AArch64 has the `Address Tagging`_ (or top-byte-ignore, TBI), a hardware 
feature that allows
 software to use 8 most significant bits of a 64-bit pointer as
 a tag. HWASAN uses `Address Tagging`_
 to implement a memory safety tool, similar to :doc:`AddressSanitizer`,
@@ -31,7 +31,7 @@ accuracy guarantees.
 Algorithm
 =
 * Every heap/stack/global memory object is forcibly aligned by `N` bytes
-  (`N` is e.g. 16 or 64)
+  (`N` is e.g. 16 or 64). We call `N` the **granularity** of tagging.
 * 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`
@@ -44,19 +44,35 @@ 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.
+All memory accesses are prefixed with an inline instruction sequence that
+verifies the tags. Currently, the following sequence is used:
 
-It's possible to inline this callback too.
+
+.. code-block:: asm
+
+  // int foo(int *a) { return *a; }
+  // clang -O2 --target=aarch64-linux -fsanitize=hwaddress -c load.c
+  foo:
+   0:  08 dc 44 d3 ubfxx8, x0, #4, #52  // shadow address
+   4:  08 01 40 39 ldrbw8, [x8] // load shadow
+   8:  09 fc 78 d3 lsr x9, x0, #56  // address tag
+   c:  3f 01 08 6b cmp w9, w8   // compare tags
+  10:  61 00 00 54 b.ne#12  // jump on mismatch
+  14:  00 00 40 b9 ldr w0, [x0] // original load
+  18:  c0 03 5f d6 ret 
+  1c:  40 20 40 d4 hlt #0x102   // halt
+  20:  00 00 40 b9 ldr w0, [x0] // original load
+  24:  c0 03 5f d6 ret
+
+
+Alternatively, memory accesses are prefixed with a function call.
 
 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.
+`free` tags the memory with a different tag.
 
 Stack
 -
@@ -75,7 +91,7 @@ TODO: details.
 Error reporting
 ---
 
-Errors are generated by `__builtin_trap` and are handled by a signal handler.
+Errors are generated by the `HLT` instruction and are handled by a signal 
handler.
 
 Attribute
 -


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


r326373 - [hwasan] update the asm snippet in the docs to match the current default behaviour

2018-02-28 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Wed Feb 28 13:58:19 2018
New Revision: 326373

URL: http://llvm.org/viewvc/llvm-project?rev=326373&view=rev
Log:
[hwasan] update the asm snippet in the docs to match the current default 
behaviour

Modified:
cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst

Modified: cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst?rev=326373&r1=326372&r2=326373&view=diff
==
--- cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst (original)
+++ cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst Wed Feb 28 
13:58:19 2018
@@ -61,8 +61,6 @@ verifies the tags. Currently, the follow
   14:  00 00 40 b9 ldr w0, [x0] // original load
   18:  c0 03 5f d6 ret 
   1c:  40 20 40 d4 hlt #0x102   // halt
-  20:  00 00 40 b9 ldr w0, [x0] // original load
-  24:  c0 03 5f d6 ret
 
 
 Alternatively, memory accesses are prefixed with a function call.


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


r327471 - [hwasan] update docs

2018-03-13 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Tue Mar 13 18:55:49 2018
New Revision: 327471

URL: http://llvm.org/viewvc/llvm-project?rev=327471&view=rev
Log:
[hwasan] update docs

Modified:
cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst

Modified: cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst?rev=327471&r1=327470&r2=327471&view=diff
==
--- cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst (original)
+++ cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst Tue Mar 13 
18:55:49 2018
@@ -7,8 +7,6 @@ This page is a design document for
 a tool similar to :doc:`AddressSanitizer`,
 but based on partial hardware assistance.
 
-The document is a draft, suggestions are welcome.
-
 
 Introduction
 
@@ -30,15 +28,16 @@ accuracy guarantees.
 
 Algorithm
 =
-* Every heap/stack/global memory object is forcibly aligned by `N` bytes
-  (`N` is e.g. 16 or 64). We call `N` the **granularity** of tagging.
-* For every such object a random `K`-bit tag `T` is chosen (`K` is e.g. 4 or 8)
+* Every heap/stack/global memory object is forcibly aligned by `TG` bytes
+  (`TG` is e.g. 16 or 64). We call `TG` the **tagging granularity**.
+* For every such object a random `TS`-bit tag `T` is chosen (`TS`, or tag 
size, 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)
+* The memory for the object is also tagged with `T` (using a `TG=>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.
 
+For a more detailed discussion of this approach see 
https://arxiv.org/pdf/1802.09517.pdf
+
 Instrumentation
 ===
 
@@ -59,8 +58,8 @@ verifies the tags. Currently, the follow
c:  3f 01 08 6b cmp w9, w8   // compare tags
   10:  61 00 00 54 b.ne#12  // jump on mismatch
   14:  00 00 40 b9 ldr w0, [x0] // original load
-  18:  c0 03 5f d6 ret 
-  1c:  40 20 40 d4 hlt #0x102   // halt
+  18:  c0 03 5f d6 ret
+  1c:  40 20 21 d4 brk #0x902   // trap
 
 
 Alternatively, memory accesses are prefixed with a function call.
@@ -69,14 +68,14 @@ 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.
+This can be based on any malloc that forces all objects to be TG-aligned.
 `free` tags the memory with a different tag.
 
 Stack
 -
 
 Stack frames are instrumented by aligning all non-promotable allocas
-by `N` and tagging stack memory in function prologue and epilogue.
+by `TG` and tagging stack memory in function prologue and epilogue.
 
 Tags for different allocas in one function are **not** generated
 independently; doing that in a function with `M` allocas would require
@@ -131,15 +130,25 @@ HWASAN:
 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.
+`(2**TS-1)/(2**TS)` 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 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.
+`1/TG` extra memory for the shadow
+and some overhead due to `TG`-aligning all objects.
+
+Supported architectures
+===
+HWASAN relies on `Address Tagging`_ which is only available on AArch64.
+For other 64-bit architectures it is possible to remove the address tags
+before every load and store by compiler instrumentation, but this variant
+will have limited deployability since not all of the code is
+typically instrumented.
+
+The HWASAN's approach is not applicable to 32-bit architectures.
 
 
 Related Work


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


Re: [clang-tools-extra] r333993 - [clangd] Rewrite JSON dispatcher loop using C IO (FILE*) instead of std::istream.

2018-06-08 Thread Kostya Serebryany via cfe-commits
Looks like this broke the clang-fuzzer:
https://oss-fuzz-build-logs.storage.googleapis.com/index.html

Step #4: /src/llvm/tools/clang/tools/extra/clangd/fuzzer/ClangdFuzzer.cpp:31:17:
error: no viable conversion from 'std::istringstream' (aka
'basic_istringstream') to 'std::FILE *' (aka '_IO_FILE *')
Step #4:   LSPServer.run(In);
Step #4: ^~
Step #4: 
/src/llvm/tools/clang/tools/extra/clangd/fuzzer/../ClangdLSPServer.h:46:23:
note: passing argument to parameter 'In' here
Step #4:   bool run(std::FILE *In,
Step #4:   ^
Step #4: 1 error generated.
Step #4: ninja: build stopped: subcommand failed.



On Tue, Jun 5, 2018 at 2:38 AM Sam McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: sammccall
> Date: Tue Jun  5 02:34:46 2018
> New Revision: 333993
>
> URL: http://llvm.org/viewvc/llvm-project?rev=333993&view=rev
> Log:
> [clangd] Rewrite JSON dispatcher loop using C IO (FILE*) instead of
> std::istream.
>
> Summary:
> The EINTR loop around getline was added to fix an issue with mac gdb, but
> seems
> to loop infinitely in rare cases on linux where the parent editor exits
> (most
> reports with VSCode).
> I can't work out how to fix this in a portable way with std::istream, but
> the
> C APIs have clearer contracts and LLVM has a RetryAfterSignal function for
> use
> with them which seems battle-tested.
>
> While here, clean up some inconsistency around \n in log messages (now
> add it only after JSON payloads), and reduce the scope of the
> long-message handling which was only really added to fight fuzzers.
>
> Reviewers: malaperle, ilya-biryukov
>
> Subscribers: klimek, ioeric, jkorous, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D47643
>
> Modified:
> clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
> clang-tools-extra/trunk/clangd/ClangdLSPServer.h
> clang-tools-extra/trunk/clangd/JSONRPCDispatcher.cpp
> clang-tools-extra/trunk/clangd/JSONRPCDispatcher.h
> clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
> clang-tools-extra/trunk/test/clangd/too_large.test
>
> Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp?rev=333993&r1=333992&r2=333993&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp (original)
> +++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp Tue Jun  5 02:34:46
> 2018
> @@ -396,7 +396,7 @@ ClangdLSPServer::ClangdLSPServer(JSONOut
>SupportedSymbolKinds(defaultSymbolKinds()),
>Server(CDB, FSProvider, /*DiagConsumer=*/*this, Opts) {}
>
> -bool ClangdLSPServer::run(std::istream &In, JSONStreamStyle InputStyle) {
> +bool ClangdLSPServer::run(std::FILE *In, JSONStreamStyle InputStyle) {
>assert(!IsDone && "Run was called before");
>
>// Set up JSONRPCDispatcher.
>
> Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.h
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.h?rev=333993&r1=333992&r2=333993&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/ClangdLSPServer.h (original)
> +++ clang-tools-extra/trunk/clangd/ClangdLSPServer.h Tue Jun  5 02:34:46
> 2018
> @@ -42,8 +42,8 @@ public:
>/// class constructor. This method must not be executed more than once
> for
>/// each instance of ClangdLSPServer.
>///
> -  /// \return Wether we received a 'shutdown' request before an 'exit'
> request
> -  bool run(std::istream &In,
> +  /// \return Whether we received a 'shutdown' request before an 'exit'
> request.
> +  bool run(std::FILE *In,
> JSONStreamStyle InputStyle = JSONStreamStyle::Standard);
>
>  private:
>
> Modified: clang-tools-extra/trunk/clangd/JSONRPCDispatcher.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/JSONRPCDispatcher.cpp?rev=333993&r1=333992&r2=333993&view=diff
>
> ==
> --- clang-tools-extra/trunk/clangd/JSONRPCDispatcher.cpp (original)
> +++ clang-tools-extra/trunk/clangd/JSONRPCDispatcher.cpp Tue Jun  5
> 02:34:46 2018
> @@ -14,6 +14,7 @@
>  #include "llvm/ADT/SmallString.h"
>  #include "llvm/ADT/StringExtras.h"
>  #include "llvm/Support/Chrono.h"
> +#include "llvm/Support/Errno.h"
>  #include "llvm/Support/SourceMgr.h"
>  #include 
>
> @@ -66,7 +67,7 @@ void JSONOutput::writeMessage(const json
>  Outs << "Content-Length: " << S.size() << "\r\n\r\n" << S;
>  Outs.flush();
>}
> -  log(llvm::Twine("--> ") + S);
> +  log(llvm::Twine("--> ") + S + "\n");
>  }
>
>  void JSONOutput::log(const Twine &Message) {
> @@ -180,27 +181,43 @@ bool JSONRPCDispatcher::call(const json:
>return true;
>  }
>
> -static llvm::Optional readStandardMessage(std::istream &In,
> +// Tries to read a line up to a

Re: [clang-tools-extra] r333993 - [clangd] Rewrite JSON dispatcher loop using C IO (FILE*) instead of std::istream.

2018-06-08 Thread Kostya Serebryany via cfe-commits
thanks!

On Fri, Jun 8, 2018 at 1:31 PM Sam McCall  wrote:

> Oops, thank you!
> r334315 should fix this.
>
>
>
> On Fri, Jun 8, 2018 at 9:45 PM Kostya Serebryany  wrote:
>
>> Looks like this broke the clang-fuzzer:
>> https://oss-fuzz-build-logs.storage.googleapis.com/index.html
>>
>> Step #4: 
>> /src/llvm/tools/clang/tools/extra/clangd/fuzzer/ClangdFuzzer.cpp:31:17: 
>> error: no viable conversion from 'std::istringstream' (aka 
>> 'basic_istringstream') to 'std::FILE *' (aka '_IO_FILE *')
>> Step #4:   LSPServer.run(In);
>> Step #4: ^~
>> Step #4: 
>> /src/llvm/tools/clang/tools/extra/clangd/fuzzer/../ClangdLSPServer.h:46:23: 
>> note: passing argument to parameter 'In' here
>> Step #4:   bool run(std::FILE *In,
>> Step #4:   ^
>> Step #4: 1 error generated.
>> Step #4: ninja: build stopped: subcommand failed.
>>
>>
>>
>> On Tue, Jun 5, 2018 at 2:38 AM Sam McCall via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: sammccall
>>> Date: Tue Jun  5 02:34:46 2018
>>> New Revision: 333993
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=333993&view=rev
>>> Log:
>>> [clangd] Rewrite JSON dispatcher loop using C IO (FILE*) instead of
>>> std::istream.
>>>
>>> Summary:
>>> The EINTR loop around getline was added to fix an issue with mac gdb,
>>> but seems
>>> to loop infinitely in rare cases on linux where the parent editor exits
>>> (most
>>> reports with VSCode).
>>> I can't work out how to fix this in a portable way with std::istream,
>>> but the
>>> C APIs have clearer contracts and LLVM has a RetryAfterSignal function
>>> for use
>>> with them which seems battle-tested.
>>>
>>> While here, clean up some inconsistency around \n in log messages (now
>>> add it only after JSON payloads), and reduce the scope of the
>>> long-message handling which was only really added to fight fuzzers.
>>>
>>> Reviewers: malaperle, ilya-biryukov
>>>
>>> Subscribers: klimek, ioeric, jkorous, cfe-commits
>>>
>>> Differential Revision: https://reviews.llvm.org/D47643
>>>
>>> Modified:
>>> clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
>>> clang-tools-extra/trunk/clangd/ClangdLSPServer.h
>>> clang-tools-extra/trunk/clangd/JSONRPCDispatcher.cpp
>>> clang-tools-extra/trunk/clangd/JSONRPCDispatcher.h
>>> clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
>>> clang-tools-extra/trunk/test/clangd/too_large.test
>>>
>>> Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp?rev=333993&r1=333992&r2=333993&view=diff
>>>
>>> ==
>>> --- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp (original)
>>> +++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp Tue Jun  5
>>> 02:34:46 2018
>>> @@ -396,7 +396,7 @@ ClangdLSPServer::ClangdLSPServer(JSONOut
>>>SupportedSymbolKinds(defaultSymbolKinds()),
>>>Server(CDB, FSProvider, /*DiagConsumer=*/*this, Opts) {}
>>>
>>> -bool ClangdLSPServer::run(std::istream &In, JSONStreamStyle InputStyle)
>>> {
>>> +bool ClangdLSPServer::run(std::FILE *In, JSONStreamStyle InputStyle) {
>>>assert(!IsDone && "Run was called before");
>>>
>>>// Set up JSONRPCDispatcher.
>>>
>>> Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.h?rev=333993&r1=333992&r2=333993&view=diff
>>>
>>> ==
>>> --- clang-tools-extra/trunk/clangd/ClangdLSPServer.h (original)
>>> +++ clang-tools-extra/trunk/clangd/ClangdLSPServer.h Tue Jun  5 02:34:46
>>> 2018
>>> @@ -42,8 +42,8 @@ public:
>>>/// class constructor. This method must not be executed more than
>>> once for
>>>/// each instance of ClangdLSPServer.
>>>///
>>> -  /// \return Wether we received a 'shutdown' request before an 'exit'
>>> request
>>> -  bool run(std::istream &In,
>>> +  /// \return Whether we received a 'shutdown' request before an 'exit'
>>> request.
>>> +  bool run(std::FILE *In,
>>> JSONStreamStyle InputStyle = JSONStreamStyle::Standard);
>>>
>>>  private:
>>>
>>> Modified: clang-tools-extra/trunk/clangd/JSONRPCDispatcher.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/JSONRPCDispatcher.cpp?rev=333993&r1=333992&r2=333993&view=diff
>>>
>>> ==
>>> --- clang-tools-extra/trunk/clangd/JSONRPCDispatcher.cpp (original)
>>> +++ clang-tools-extra/trunk/clangd/JSONRPCDispatcher.cpp Tue Jun  5
>>> 02:34:46 2018
>>> @@ -14,6 +14,7 @@
>>>  #include "llvm/ADT/SmallString.h"
>>>  #include "llvm/ADT/StringExtras.h"
>>>  #include "llvm/Support/Chrono.h"
>>> +#include "llvm/Support/Errno.h"
>>>  #include "llvm/Support/SourceMgr.h"
>>>  #include 
>>>
>>> @@ -66,7 +67,7 @@ void JSONOutput::w

r352818 - [sanitizer-coverage] prune trace-cmp instrumentation for CMP isntructions that feed into the backedge branch. Instrumenting these CMP instructions is almost always useless (and harmful) for

2019-01-31 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Thu Jan 31 15:43:00 2019
New Revision: 352818

URL: http://llvm.org/viewvc/llvm-project?rev=352818&view=rev
Log:
[sanitizer-coverage] prune trace-cmp instrumentation for CMP isntructions that 
feed into the backedge branch. Instrumenting these CMP instructions is almost 
always useless (and harmful) for fuzzing

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=352818&r1=352817&r2=352818&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Thu Jan 31 15:43:00 2019
@@ -248,6 +248,9 @@ and with  ``-fsanitize-coverage=trace-ge
 the `LLVM GEP instructions `_
 (to capture array indices).
 
+Unless ``no-prune`` option is provided, some of the comparison instructions
+will not be instrumented.
+
 .. code-block:: c++
 
   // Called before a comparison instruction.


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


r311794 - [sanitizer-coverage] extend fsanitize-coverage=pc-table with flags for every PC

2017-08-25 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Fri Aug 25 12:29:47 2017
New Revision: 311794

URL: http://llvm.org/viewvc/llvm-project?rev=311794&view=rev
Log:
[sanitizer-coverage] extend fsanitize-coverage=pc-table with flags for every PC

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=311794&r1=311793&r2=311794&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Fri Aug 25 12:29:47 2017
@@ -148,19 +148,21 @@ With ``-fsanitize-coverage=pc-table`` th
 instrumented PCs. Requires either ``-fsanitize-coverage=inline-8bit-counters`` 
or
 ``-fsanitize-coverage=trace-pc-guard``.
 
-Users need to implement a single function to capture the counters at startup:
+Users need to implement a single function to capture the PC table at startup:
 
 .. code-block:: c++
 
   extern "C"
-  void __sanitizer_cov_pcs_init(const uint8_t *pcs_beg,
-const uint8_t *pcs_end) {
+  void __sanitizer_cov_pcs_init(const uintptr_t *pcs_beg,
+const uintptr_t *pcs_end) {
 // [pcs_beg,pcs_end) is the array of ptr-sized integers representing
-// PCs of the instrumented blocks in the current DSO.
-// Capture this array in order to read the PCs.
-// The number of PCs for a given DSO is the same as the number of
-// 8-bit counters (-fsanitize-coverage=inline-8bit-counters) or
+// pairs [PC,PCFlags] for every instrumented block in the current DSO.
+// Capture this array in order to read the PCs and their Flags.
+// The number of PCs and PCFlags for a given DSO is the same as the number
+// of 8-bit counters (-fsanitize-coverage=inline-8bit-counters) or
 // trace_pc_guard callbacks (-fsanitize-coverage=trace-pc-guard)
+// A PCFlags describes the basic block:
+//  * bit0: 1 if the block is the function entry block, 0 otherwise.
   }
 
 


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


r312346 - [libFuzzer] switch -fsanitize=fuzzer from trace-pc-guard to inline-8bit-counters

2017-09-01 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Fri Sep  1 11:34:36 2017
New Revision: 312346

URL: http://llvm.org/viewvc/llvm-project?rev=312346&view=rev
Log:
[libFuzzer] switch -fsanitize=fuzzer from trace-pc-guard to inline-8bit-counters

Modified:
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/test/Driver/fuzzer.c

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=312346&r1=312345&r2=312346&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Fri Sep  1 11:34:36 2017
@@ -313,7 +313,7 @@ SanitizerArgs::SanitizerArgs(const ToolC
 
   // Enable coverage if the fuzzing flag is set.
   if (Add & FuzzerNoLink) {
-CoverageFeatures |= CoverageTracePCGuard | CoverageIndirCall |
+CoverageFeatures |= CoverageInline8bitCounters | CoverageIndirCall |
 CoverageTraceCmp | CoveragePCTable;
 // Due to TLS differences, stack depth tracking is only enabled on 
Linux
 if (TC.getTriple().isOSLinux())

Modified: cfe/trunk/test/Driver/fuzzer.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fuzzer.c?rev=312346&r1=312345&r2=312346&view=diff
==
--- cfe/trunk/test/Driver/fuzzer.c (original)
+++ cfe/trunk/test/Driver/fuzzer.c Fri Sep  1 11:34:36 2017
@@ -3,7 +3,7 @@
 // RUN: %clang -fsanitize=fuzzer %s -target x86_64-apple-darwin14 -### 2>&1 | 
FileCheck --check-prefixes=CHECK-FUZZER-LIB,CHECK-COVERAGE-FLAGS %s
 //
 // CHECK-FUZZER-LIB: libclang_rt.fuzzer
-// CHECK-COVERAGE: -fsanitize-coverage-trace-pc-guard
+// CHECK-COVERAGE: -fsanitize-coverage-inline-8bit-counters
 // CHECK-COVERAGE-SAME: -fsanitize-coverage-indirect-calls
 // CHECK-COVERAGE-SAME: -fsanitize-coverage-trace-cmp
 // CHECK-COVERAGE-SAME: -fsanitize-coverage-pc-table
@@ -24,7 +24,7 @@
 // Check that we don't link in libFuzzer when compiling with 
-fsanitize=fuzzer-no-link.
 // RUN: %clang -fsanitize=fuzzer-no-link %s -target x86_64-apple-darwin14 -### 
2>&1 | FileCheck --check-prefixes=CHECK-NOLIB,CHECK-COV %s
 // CHECK-NOLIB-NOT: libclang_rt.libfuzzer
-// CHECK-COV: -fsanitize-coverage-trace-pc-guard
+// CHECK-COV: -fsanitize-coverage-inline-8bit-counters
 
 // RUN: %clang -fsanitize=fuzzer -fsanitize-coverage=trace-pc %s -### 2>&1 | 
FileCheck --check-prefixes=CHECK-MSG %s
 // CHECK-MSG-NOT: argument unused during compilation


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


Re: [libcxxabi] r313215 - Reland "When built with ASan, __cxa_throw calls __asan_handle_no_return"

2017-09-14 Thread Kostya Serebryany via cfe-commits
The bot is unhappy:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/7880/steps/build%20libcxx%2Fasan/logs/stdio

1/6] Building CXX object
projects/libcxxabi/src/CMakeFiles/cxxabi_objects.dir/cxa_exception.cpp.o
FAILED: projects/libcxxabi/src/CMakeFiles/cxxabi_objects.dir/cxa_exception.cpp.o
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm_build0/bin/clang++
  -DHAVE___CXA_THREAD_ATEXIT_IMPL -D_DEBUG -D_GNU_SOURCE
-D_LIBCPP_DISABLE_EXTERN_TEMPLATE -D_LIBCXXABI_BUILDING_LIBRARY
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Iprojects/libcxxabi/src
-I/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/projects/libcxxabi/src
-I/usr/include/libxml2 -Iinclude
-I/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/include
-I/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/projects/libcxxabi/include
-I/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/projects/libcxx/include
-fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall
-W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-Wstring-conversion -fno-omit-frame-pointer -gline-tables-only
-fsanitize=address -fsanitize-address-use-after-scope
-fcolor-diagnostics -ffunction-sections -fdata-sections  -O3  -fPIC
-UNDEBUG -nostdinc++ -Werror=return-type -W -Wall -Wchar-subscripts
-Wconversion -Wmismatched-tags -Wmissing-braces -Wnewline-eof
-Wunused-function -Wshadow -Wshorten-64-to-32 -Wsign-compare
-Wsign-conversion -Wstrict-aliasing=2 -Wstrict-overflow=4
-Wunused-parameter -Wunused-variable -Wwrite-strings -Wundef
-Wno-error -pedantic -fstrict-aliasing -funwind-tables -D_DEBUG
-UNDEBUG -std=c++11 -MD -MT
projects/libcxxabi/src/CMakeFiles/cxxabi_objects.dir/cxa_exception.cpp.o
-MF projects/libcxxabi/src/CMakeFiles/cxxabi_objects.dir/cxa_exception.cpp.o.d
-o projects/libcxxabi/src/CMakeFiles/cxxabi_objects.dir/cxa_exception.cpp.o
-c 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/projects/libcxxabi/src/cxa_exception.cpp
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/projects/libcxxabi/src/cxa_exception.cpp:227:5:
error: use of undeclared identifier '__asan_handle_no_return'
__asan_handle_no_return();
^


On Wed, Sep 13, 2017 at 4:35 PM, Petr Hosek via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: phosek
> Date: Wed Sep 13 16:35:07 2017
> New Revision: 313215
>
> URL: http://llvm.org/viewvc/llvm-project?rev=313215&view=rev
> Log:
> Reland "When built with ASan, __cxa_throw calls __asan_handle_no_return"
>
> The ASan runtime on many systems intercepts cxa_throw just so it
> can call asan_handle_no_return first. Some newer systems such as
> Fuchsia don't use interceptors on standard library functions at all,
> but instead use sanitizer-instrumented versions of the standard
> libraries. When libc++abi is built with ASan, cxa_throw can just
> call asan_handle_no_return itself so no interceptor is required.
>
> Patch by Roland McGrath
>
> Differential Revision: https://reviews.llvm.org/D37229
>
> Modified:
> libcxxabi/trunk/src/cxa_exception.cpp
>
> Modified: libcxxabi/trunk/src/cxa_exception.cpp
> URL: http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/
> cxa_exception.cpp?rev=313215&r1=313214&r2=313215&view=diff
> 
> ==
> --- libcxxabi/trunk/src/cxa_exception.cpp (original)
> +++ libcxxabi/trunk/src/cxa_exception.cpp Wed Sep 13 16:35:07 2017
> @@ -19,6 +19,10 @@
>  #include "cxa_handlers.hpp"
>  #include "fallback_malloc.h"
>
> +#if __has_feature(address_sanitizer)
> +#include 
> +#endif
> +
>  // +---+-+-
> --+
>  // | __cxa_exception   | _Unwind_Exception CLNGC++\0 | thrown
> object |
>  // +---+-+-
> --+
> @@ -217,6 +221,12 @@ __cxa_throw(void *thrown_object, std::ty
>  globals->uncaughtExceptions += 1;   // Not atomically, since globals
> are thread-local
>
>  exception_header->unwindHeader.exception_cleanup =
> exception_cleanup_func;
> +
> +#if __has_feature(address_sanitizer)
> +// Inform the ASan runtime that now might be a good time to clean
> stuff up.
> +__asan_handle_no_return();
> +#endif
> +
>  #ifdef __USING_SJLJ_EXCEPTIONS__
>  _Unwind_SjLj_RaiseException(&exception_header->unwindHeader);
>  #else
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r331238 - [ShadowCallStack] fix the docs

2018-04-30 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Mon Apr 30 17:15:56 2018
New Revision: 331238

URL: http://llvm.org/viewvc/llvm-project?rev=331238&view=rev
Log:
[ShadowCallStack] fix the docs

Modified:
cfe/trunk/docs/ShadowCallStack.rst

Modified: cfe/trunk/docs/ShadowCallStack.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ShadowCallStack.rst?rev=331238&r1=331237&r2=331238&view=diff
==
--- cfe/trunk/docs/ShadowCallStack.rst (original)
+++ cfe/trunk/docs/ShadowCallStack.rst Mon Apr 30 17:15:56 2018
@@ -137,7 +137,7 @@ Generates the following x86_64 assembly
 .. code-block:: gas
 
 push   %rax
-callq  foo
+callq  bar
 add$0x1,%eax
 pop%rcx
 retq
@@ -165,7 +165,7 @@ assembly:
 mov%gs:(%r11),%r11
 mov%r10,%gs:(%r11)
 push   %rax
-callq  foo
+callq  bar
 add$0x1,%eax
 pop%rcx
 xor%r11,%r11


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


r281845 - [libFuzzer] use 'if guard' instead of 'if guard >= 0' with trace-pc; change the guard type to intptr_t; use separate array for 8-bit counters

2016-09-17 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Sat Sep 17 23:52:23 2016
New Revision: 281845

URL: http://llvm.org/viewvc/llvm-project?rev=281845&view=rev
Log:
[libFuzzer] use 'if guard' instead of 'if guard >= 0' with trace-pc; change the 
guard type to intptr_t; use separate array for 8-bit counters

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=281845&r1=281844&r2=281845&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Sat Sep 17 23:52:23 2016
@@ -331,10 +331,10 @@ on every edge:
 
 .. code-block:: none
 
-   if (guard_variable >= 0)
+   if (guard_variable)
  __sanitizer_cov_trace_pc_guard(&guard_variable)
 
-Every edge will have its own 8-byte `guard_variable`.
+Every edge will have its own `guard_variable` (uintptr_t).
 
 The compler will also insert a module constructor that will call
 
@@ -342,7 +342,7 @@ The compler will also insert a module co
 
// The guards are [start, stop).
// This function may be called multiple times with the same values of 
start/stop.
-   __sanitizer_cov_trace_pc_guard_init(uint64_t *start, uint64_t *stop);
+   __sanitizer_cov_trace_pc_guard_init(uintptr_t *start, uintptr_t *stop);
 
 Similarly to `trace-pc,indirect-calls`, with `trace-pc-guards,indirect-calls`
 ``__sanitizer_cov_trace_pc_indirect(void *callee)`` will be inserted on every 
indirect call.


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


Re: r282453 - P0145R3 (C++17 evaluation order tweaks): consistently emit the LHS of array

2016-09-26 Thread Kostya Serebryany via cfe-commits
Looks like yours:

FAILED: tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/CGExpr.cpp.obj
C:\PROGRA~2\MICROS~1.0\VC\bin\AMD64_~1\cl.exe   /nologo /TP
-DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_OBJC_REWRITER
-DCLANG_ENABLE_STATIC_ANALYZER -DGTEST_HAS_RTTI=0 -DUNICODE
-D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS
-D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS
-D_DEBUG_POINTER_IMPL="" -D_GNU_SOURCE -D_HAS_EXCEPTIONS=0
-D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Itools\clang\lib\CodeGen
-IC:\b\slave\sanitizer-windows\llvm\tools\clang\lib\CodeGen
-IC:\b\slave\sanitizer-windows\llvm\tools\clang\include
-Itools\clang\include -Iinclude
-IC:\b\slave\sanitizer-windows\llvm\include /DWIN32 /D_WINDOWS   /W4
-wd4141 -wd4146 -wd4180 -wd4244 -wd4258 -wd4267 -wd4291 -wd4345
-wd4351 -wd4355 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624
-wd4722 -wd4800 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510
-wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611
-wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4324 -w14062
-we4238 /Zc:inline /Oi /Zc:rvalueCast /MD /O2 /Ob2   -UNDEBUG  /EHs-c-
/GR- /showIncludes
/Fotools\clang\lib\CodeGen\CMakeFiles\clangCodeGen.dir\CGExpr.cpp.obj
/Fdtools\clang\lib\CodeGen\CMakeFiles\clangCodeGen.dir\ /FS -c
C:\b\slave\sanitizer-windows\llvm\tools\clang\lib\CodeGen\CGExpr.cpp
C:\b\slave\sanitizer-windows\llvm\tools\clang\lib\CodeGen\CGExpr.cpp(2900)
: error C3486: a parameter for a lambda cannot have a default argument
ninja: build stopped: subcommand failed.program finished with exit code 1


On Mon, Sep 26, 2016 at 4:49 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Mon Sep 26 18:49:47 2016
> New Revision: 282453
>
> URL: http://llvm.org/viewvc/llvm-project?rev=282453&view=rev
> Log:
> P0145R3 (C++17 evaluation order tweaks): consistently emit the LHS of array
> subscripting before the RHS, regardless of which is the base and which is
> the
> index.
>
> Added:
> cfe/trunk/test/CodeGenCXX/cxx1z-eval-order.cpp
> Modified:
> cfe/trunk/lib/CodeGen/CGExpr.cpp
> cfe/trunk/test/CodeGen/captured-statements-nested.c
> cfe/trunk/test/CodeGenCXX/catch-undef-behavior.cpp
> cfe/trunk/test/CodeGenCXX/cxx1y-initializer-aggregate.cpp
> cfe/trunk/test/CodeGenCXX/pragma-loop-safety.cpp
> cfe/trunk/test/CodeGenCXX/vla-lambda-capturing.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> CGExpr.cpp?rev=282453&r1=282452&r2=282453&view=diff
> 
> ==
> --- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGExpr.cpp Mon Sep 26 18:49:47 2016
> @@ -2875,13 +2875,30 @@ static Address emitArraySubscriptGEP(Cod
>
>  LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr
> *E,
> bool Accessed) {
> -  // The index must always be an integer, which is not an aggregate.
> Emit it.
> -  llvm::Value *Idx = EmitScalarExpr(E->getIdx());
> -  QualType IdxTy  = E->getIdx()->getType();
> -  bool IdxSigned = IdxTy->isSignedIntegerOrEnumerationType();
> +  // The index must always be an integer, which is not an aggregate.
> Emit it
> +  // in lexical order (this complexity is, sadly, required by C++17).
> +  llvm::Value *IdxPre =
> +  (E->getLHS() == E->getIdx()) ? EmitScalarExpr(E->getIdx()) :
> nullptr;
> +  auto EmitIdxAfterBase = [&, IdxPre](bool Promote = true) -> llvm::Value
> * {
> +auto *Idx = IdxPre;
> +if (E->getLHS() != E->getIdx()) {
> +  assert(E->getRHS() == E->getIdx() && "index was neither LHS nor
> RHS");
> +  Idx = EmitScalarExpr(E->getIdx());
> +}
> +
> +QualType IdxTy = E->getIdx()->getType();
> +bool IdxSigned = IdxTy->isSignedIntegerOrEnumerationType();
> +
> +if (SanOpts.has(SanitizerKind::ArrayBounds))
> +  EmitBoundsCheck(E, E->getBase(), Idx, IdxTy, Accessed);
>
> -  if (SanOpts.has(SanitizerKind::ArrayBounds))
> -EmitBoundsCheck(E, E->getBase(), Idx, IdxTy, Accessed);
> +// Extend or truncate the index type to 32 or 64-bits.
> +if (Promote && Idx->getType() != IntPtrTy)
> +  Idx = Builder.CreateIntCast(Idx, IntPtrTy, IdxSigned, "idxprom");
> +
> +return Idx;
> +  };
> +  IdxPre = nullptr;
>
>// If the base is a vector type, then we are forming a vector element
> lvalue
>// with this subscript.
> @@ -2889,6 +2906,7 @@ LValue CodeGenFunction::EmitArraySubscri
>!isa(E->getBase())) {
>  // Emit the vector as an lvalue to get its address.
>  LValue LHS = EmitLValue(E->getBase());
> +auto *Idx = EmitIdxAfterBase(/*Promote*/false);
>  assert(LHS.isSimple() && "Can only subscript lvalue vectors here!");
>  return LValue::MakeVectorElt(LHS.getAddress(), Idx,
>   E->getBase()->getTy

r282735 - [sanitizer-coverage/libFuzzer] make the guards for trace-pc 32-bit; create one array of guards per function, instead of one guard per BB. reorganize the code so that trace-pc-guard does not

2016-09-29 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Thu Sep 29 12:43:24 2016
New Revision: 282735

URL: http://llvm.org/viewvc/llvm-project?rev=282735&view=rev
Log:
[sanitizer-coverage/libFuzzer] make the guards for trace-pc 32-bit; create one 
array of guards per function, instead of one guard per BB. reorganize the code 
so that trace-pc-guard does not create unneeded globals

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=282735&r1=282734&r2=282735&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Thu Sep 29 12:43:24 2016
@@ -334,7 +334,7 @@ on every edge:
if (guard_variable)
  __sanitizer_cov_trace_pc_guard(&guard_variable)
 
-Every edge will have its own `guard_variable` (uintptr_t).
+Every edge will have its own `guard_variable` (uint32_t).
 
 The compler will also insert a module constructor that will call
 
@@ -342,7 +342,7 @@ The compler will also insert a module co
 
// The guards are [start, stop).
// This function may be called multiple times with the same values of 
start/stop.
-   __sanitizer_cov_trace_pc_guard_init(uintptr_t *start, uintptr_t *stop);
+   __sanitizer_cov_trace_pc_guard_init(uint32_t_t *start, uint32_t *stop);
 
 Similarly to `trace-pc,indirect-calls`, with `trace-pc-guards,indirect-calls`
 ``__sanitizer_cov_trace_pc_indirect(void *callee)`` will be inserted on every 
indirect call.


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


r282749 - [sanitize-coverage] doc typo

2016-09-29 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Thu Sep 29 13:34:40 2016
New Revision: 282749

URL: http://llvm.org/viewvc/llvm-project?rev=282749&view=rev
Log:
[sanitize-coverage] doc typo

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=282749&r1=282748&r2=282749&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Thu Sep 29 13:34:40 2016
@@ -342,7 +342,7 @@ The compler will also insert a module co
 
// The guards are [start, stop).
// This function may be called multiple times with the same values of 
start/stop.
-   __sanitizer_cov_trace_pc_guard_init(uint32_t_t *start, uint32_t *stop);
+   __sanitizer_cov_trace_pc_guard_init(uint32_t *start, uint32_t *stop);
 
 Similarly to `trace-pc,indirect-calls`, with `trace-pc-guards,indirect-calls`
 ``__sanitizer_cov_trace_pc_indirect(void *callee)`` will be inserted on every 
indirect call.


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


r282751 - [sanitizer-coverage] more docs

2016-09-29 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Thu Sep 29 13:58:17 2016
New Revision: 282751

URL: http://llvm.org/viewvc/llvm-project?rev=282751&view=rev
Log:
[sanitizer-coverage] more docs

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=282751&r1=282750&r2=282751&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Thu Sep 29 13:58:17 2016
@@ -349,6 +349,73 @@ Similarly to `trace-pc,indirect-calls`,
 
 The functions `__sanitizer_cov_trace_pc_*` should be defined by the user.
 
+Example: 
+
+.. code-block:: c++
+
+  // trace-pc-guard-cb.cc
+  #include 
+  #include 
+  #include 
+
+  // This callback is inserted by the compiler as a module constructor
+  // into every compilation unit. 'start' and 'stop' correspond to the
+  // beginning and end of the section with the guards for the entire
+  // binary (executable or DSO) and so it will be called multiple times
+  // with the same parameters.
+  extern "C" void __sanitizer_cov_trace_pc_guard_init(uint32_t *start,
+  uint32_t *stop) {
+static uint64_t N;  // Counter for the guards.
+if (start == stop || *start) return;  // Initialize only once.
+printf("INIT: %p %p\n", start, stop);
+for (uint32_t *x = start; x < stop; x++)
+  *x = ++N;  // Guards should start from 1.
+  }
+
+  // This callback is inserted by the compiler on every edge in the
+  // control flow (some optimizations apply).
+  // Typically, the compiler will emit the code like this:
+  //if(*guard)
+  //  __sanitizer_cov_trace_pc_guard(guard);
+  // But for large functions it will emit a simple call:
+  //__sanitizer_cov_trace_pc_guard(guard);
+  extern "C" void __sanitizer_cov_trace_pc_guard(uint32_t *guard) {
+if (!*guard) return;  // Duplicate the guard check.
+// If you set *guard to 0 this code will not be called again for this edge.
+// Now you can get the PC and do whatever you want: 
+//   store it somewhere or symbolize it and print right away.
+// The values of `*guard` are as you set them in
+// __sanitizer_cov_trace_pc_guard_init and so you can make the consecutive
+// and use them to dereference an array or a bit vector.
+void *PC = __builtin_return_address(0);
+char PcDescr[1024];
+// This function is a part of the sanitizer run-time.
+// To use it, link with AddressSanitizer or other sanitizer.
+__sanitizer_symbolize_pc(PC, "%p %F %L", PcDescr, sizeof(PcDescr));
+printf("guard: %p %x PC %s\n", guard, *guard, PcDescr);
+  }
+
+.. code-block:: c++
+
+  // trace-pc-guard-example.cc
+  void foo() { }
+  int main(int argc, char **argv) {
+if (argc > 1) foo();
+  }
+
+.. code-block:: console
+  
+  clang++ -g  -fsanitize-coverage=trace-pc-guard trace-pc-guard-example.cc -c
+  clang++ trace-pc-guard-cb.cc trace-pc-guard-example.o -fsanitize=address
+  ASAN_OPTIONS=strip_path_prefix=`pwd`/ ./a.out
+
+.. code-block:: console
+
+  INIT: 0x71bcd0 0x71bce0
+  guard: 0x71bcd4 2 PC 0x4ecd5b in main trace-pc-guard-example.cc:2
+  guard: 0x71bcd8 3 PC 0x4ecd9e in main trace-pc-guard-example.cc:3:7
+
+
 Tracing data flow
 =
 


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


r282752 - [sanitizer-coverage] a bit more docs

2016-09-29 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Thu Sep 29 14:06:09 2016
New Revision: 282752

URL: http://llvm.org/viewvc/llvm-project?rev=282752&view=rev
Log:
[sanitizer-coverage] a bit more docs

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=282752&r1=282751&r2=282752&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Thu Sep 29 14:06:09 2016
@@ -385,7 +385,7 @@ Example:
 // Now you can get the PC and do whatever you want: 
 //   store it somewhere or symbolize it and print right away.
 // The values of `*guard` are as you set them in
-// __sanitizer_cov_trace_pc_guard_init and so you can make the consecutive
+// __sanitizer_cov_trace_pc_guard_init and so you can make them consecutive
 // and use them to dereference an array or a bit vector.
 void *PC = __builtin_return_address(0);
 char PcDescr[1024];
@@ -415,6 +415,18 @@ Example:
   guard: 0x71bcd4 2 PC 0x4ecd5b in main trace-pc-guard-example.cc:2
   guard: 0x71bcd8 3 PC 0x4ecd9e in main trace-pc-guard-example.cc:3:7
 
+.. code-block:: console
+
+  ASAN_OPTIONS=strip_path_prefix=`pwd`/ ./a.out with-foo
+
+
+.. code-block:: console
+
+  INIT: 0x71bcd0 0x71bce0
+  guard: 0x71bcd4 2 PC 0x4ecd5b in main trace-pc-guard-example.cc:3
+  guard: 0x71bcdc 4 PC 0x4ecdc7 in main trace-pc-guard-example.cc:4:17
+  guard: 0x71bcd0 1 PC 0x4ecd20 in foo() trace-pc-guard-example.cc:2:14
+
 
 Tracing data flow
 =


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


r282962 - [sanitizer-coverage] fix docs

2016-09-30 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Fri Sep 30 16:57:10 2016
New Revision: 282962

URL: http://llvm.org/viewvc/llvm-project?rev=282962&view=rev
Log:
[sanitizer-coverage] fix docs

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=282962&r1=282961&r2=282962&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Fri Sep 30 16:57:10 2016
@@ -131,6 +131,7 @@ in debug info of the binary. Thus the ``
 to produce a ``.symcov`` file first:
 
 .. code-block:: console
+
 sancov -symbolize my_program.123.sancov my_program > my_program.123.symcov
 
 The ``.symcov`` file can be browsed overlayed over the source code by


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


[PATCH] D25199: [ubsan] Sanitize deleted pointers

2016-10-03 Thread Kostya Serebryany via cfe-commits
kcc added a reviewer: pcc.
kcc added a comment.

In https://reviews.llvm.org/D25199#559407, @vsk wrote:

> It looks like programs which trip -fsanitize-value-after-delete will just 
> crash without further reporting, which isn't in keeping with the way other 
> ubsan checks are implemented.
>
> IMO, address sanitizer is better-equipped to diagnose this issue.


of course, but asan's overhead is much greater. 
This tool might be fast enough to be always on in production.

The code looks reasonable to me, but as I am not too familiar with clang code, 
so asking pcc@ to have a look.

Also, please

- update the ubsan documentation
- add a runnable test to compiler-rt/test/ubsan


https://reviews.llvm.org/D25199



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


[PATCH] D25199: [ubsan] Sanitize deleted pointers

2016-10-03 Thread Kostya Serebryany via cfe-commits
kcc added a comment.

>>   will just crash without further reporting

I agree, and we can address that by having special logic in ubsan's segv 
handler. 
This does not have to be in this patch.

Also, I am not sure about the actual constant. 
DEADBEEF is commonly recognized poison valued, but on a 32-bit system it may 
actually be a valid pointer.


https://reviews.llvm.org/D25199



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


[PATCH] D25199: [ubsan] Sanitize deleted pointers

2016-10-03 Thread Kostya Serebryany via cfe-commits
kcc added a comment.



> Maybe we could call this `-fpoison-dangling-ptrs` and force users to be more 
> explicit about opting into this behavior change. That would remove some of 
> the constraints usually placed on new sanitizer checks (e.g support for 
> executing after the error triggers, support for custom trap functions).

What's wrong with -fsanitize=SOMETHING? (the exact value of SOMETHING is 
debatable)

>> @kcc Is it safe to add a handler for segv and continue program execution as 
>> normal? I'm asking because I haven't tried that before, and am guessing you 
>> have experience with this from working on asan.

Not sure I understand your question. 
We can add an optional SEGV handler to ubsan that will see the address on which 
we failed, and say something like "faulty address is close to 0xDEADBEEF, use 
of dangling pointer suspected. "
Then exit.

>> One more thing to consider: how will we support 
>> -fsanitize-trap=value-after-delete?

This will essentially only have the trap mode, it will not support 
-fsanitize-recover



> Sanitizers.def:105
> +Null | ObjectSize | Return | ReturnsNonnullAttribute | 
> Shift |
> +SignedIntegerOverflow | ValueAfterDelete | VLABound |
> +Unreachable | Function | Vptr)

Agree with Peter's concern -- it may break rare valid cases, so it should not 
be in this group. 
We already have unsigned-integer-overflow that will also break valid code, so 
it's fine to have a second case like that.

https://reviews.llvm.org/D25199



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


r284029 - Document potential implementation of CFI in hardware.

2016-10-12 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Wed Oct 12 13:33:54 2016
New Revision: 284029

URL: http://llvm.org/viewvc/llvm-project?rev=284029&view=rev
Log:
Document potential implementation of CFI in hardware.

Summary: Document potential implementation of CFI in hardware.

Reviewers: eugenis, pcc

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D25455

Modified:
cfe/trunk/docs/ControlFlowIntegrityDesign.rst

Modified: cfe/trunk/docs/ControlFlowIntegrityDesign.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ControlFlowIntegrityDesign.rst?rev=284029&r1=284028&r2=284029&view=diff
==
--- cfe/trunk/docs/ControlFlowIntegrityDesign.rst (original)
+++ cfe/trunk/docs/ControlFlowIntegrityDesign.rst Wed Oct 12 13:33:54 2016
@@ -497,3 +497,57 @@ Cross-DSO CFI mode requires that the mai
 In non-PIE executables the address of an external function (taken from
 the main executable) is the address of that function’s PLT record in
 the main executable. This would break the CFI checks.
+
+
+Hardware support
+
+
+We believe that the above design can be efficiently implemented in hardware.
+A single new instruction added to an ISA would allow to perform the CFI check
+with fewer bytes per check (smaller code size overhead) and potentially more
+efficiently. The current software-only instrumentation requires at least
+32-bytes per check (on x86_64).
+A hardware instruction may probably be less than ~ 12 bytes.
+Such instruction would check that the argument pointer is in-bounds,
+and is properly aligned, and if the checks fail it will either trap (in 
monolithic scheme)
+or call the slow path function (cross-DSO scheme).
+The bit vector lookup is probably too complex for a hardware implementation.
+
+.. code-block:: none
+
+  //  This instruction checks that 'Ptr'
+  //   * is aligned by (1 << kAlignment) and
+  //   * is inside [kRangeBeg, kRangeBeg+(kRangeSize<= kRangeBeg + (kRangeSize << kAlignment) ||
+ Ptr & ((1 << kAlignment) - 1))
+   Jump(kFailedCheckTarget);
+  }
+
+An alternative and more compact enconding would not use `kFailedCheckTarget`,
+and will trap on check failure instead.
+This will allow us to fit the instruction into **8-9 bytes**.
+The cross-DSO checks will be performed by a trap handler and
+performance-critical ones will have to be black-listed and checked using the
+software-only scheme.
+
+Note that such hardware extension would be complementary to checks
+at the callee side, such as e.g. **Intel ENDBRANCH**.
+Moreover, CFI would have two benefits over ENDBRANCH: a) precision and b)
+ability to protect against invalid casts between polymorphic types.


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


Status of CET support? (Re: [PATCH] D40224:...)

2017-11-27 Thread Kostya Serebryany via cfe-commits
Hi,

I see these patches for the CET support in LLVM -- great!
Could you please also tell us
  * what's the status of the Linux Kernel and Glibc support for CET?
  * how we can start evaluating the hardware feature (simulators, etc)?

Thanks!

--kcc


On Sun, Nov 26, 2017 at 4:35 AM, Phabricator via Phabricator via
cfe-commits  wrote:

> This revision was automatically updated to reflect the committed changes.
> Closed by commit rL318995: Control-Flow Enforcement Technology - Shadow
> Stack and Indirect Branch Tracking… (authored by orenb).
>
> Changed prior to commit:
>   https://reviews.llvm.org/D40224?vs=123937&id=124287#toc
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D40224
>
> Files:
>   cfe/trunk/include/clang/Basic/BuiltinsX86.def
>   cfe/trunk/include/clang/Basic/BuiltinsX86_64.def
>   cfe/trunk/include/clang/Driver/Options.td
>   cfe/trunk/lib/Basic/Targets/X86.cpp
>   cfe/trunk/lib/Basic/Targets/X86.h
>   cfe/trunk/lib/Headers/CMakeLists.txt
>   cfe/trunk/lib/Headers/cetintrin.h
>   cfe/trunk/lib/Headers/immintrin.h
>   cfe/trunk/test/CodeGen/builtins-x86.c
>   cfe/trunk/test/CodeGen/cetintrin.c
>   cfe/trunk/test/Driver/x86-target-features.c
>   cfe/trunk/test/Preprocessor/x86_target_features.c
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r319684 - design document for a hardware-assisted memory safety (HWAMS) tool, similar to AddressSanitizer

2017-12-04 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Mon Dec  4 12:01:38 2017
New Revision: 319684

URL: http://llvm.org/viewvc/llvm-project?rev=319684&view=rev
Log:
design document for a hardware-assisted memory safety (HWAMS) tool, similar to 
AddressSanitizer

Summary:
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.

Reviewers: eugenis, alekseyshl

Reviewed By: eugenis

Subscribers: davidxl, cryptoad, fedor.sergeev, cfe-commits, llvm-commits

Differential Revision: https://reviews.llvm.org/D40568

Added:
cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst
Modified:
cfe/trunk/docs/index.rst

Added: cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst?rev=319684&view=auto
==
--- cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst (added)
+++ cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst Mon Dec  4 
12:01:38 2017
@@ -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

r320075 - update hwasan docs

2017-12-07 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Thu Dec  7 11:21:30 2017
New Revision: 320075

URL: http://llvm.org/viewvc/llvm-project?rev=320075&view=rev
Log:
update hwasan docs

Summary:
* use more readable name
* document the hwasan attribute

Reviewers: eugenis

Reviewed By: eugenis

Subscribers: llvm-commits, cfe-commits

Differential Revision: https://reviews.llvm.org/D40938

Modified:
cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst

Modified: cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst?rev=320075&r1=320074&r2=320075&view=diff
==
--- cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst (original)
+++ cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst Thu Dec  7 
11:21:30 2017
@@ -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 @@ See the `AddressSanitizer paper`_ for de
 
 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 @@ Error reporting
 
 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,7 +106,8 @@ HardwareAssistedAddressSanitizer:
   * 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.
@@ -99,7 +115,7 @@ HardwareAssistedAddressSanitizer:
 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.


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


r320168 - [hwasan] typo in docs

2017-12-08 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Fri Dec  8 10:14:03 2017
New Revision: 320168

URL: http://llvm.org/viewvc/llvm-project?rev=320168&view=rev
Log:
[hwasan] typo in docs

Modified:
cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst

Modified: cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst?rev=320168&r1=320167&r2=320168&view=diff
==
--- cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst (original)
+++ cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst Fri Dec  8 
10:14:03 2017
@@ -80,7 +80,7 @@ Errors are generated by `__builtin_trap`
 Attribute
 -
 
-HWASAN uses it's own LLVM IR Attribute `sanitize_hwaddress` and a matching
+HWASAN uses its 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:
 


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


r310136 - [libFuzzer] add -fsanitize-coverage-pc-table to -fsanitize=fuzzer

2017-08-04 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Fri Aug  4 14:35:11 2017
New Revision: 310136

URL: http://llvm.org/viewvc/llvm-project?rev=310136&view=rev
Log:
[libFuzzer] add -fsanitize-coverage-pc-table to -fsanitize=fuzzer

Modified:
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/test/Driver/fuzzer.c

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=310136&r1=310135&r2=310136&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Fri Aug  4 14:35:11 2017
@@ -288,7 +288,8 @@ SanitizerArgs::SanitizerArgs(const ToolC
 
   // Enable coverage if the fuzzing flag is set.
   if (Add & Fuzzer)
-CoverageFeatures |= CoverageTracePCGuard | CoverageIndirCall | 
CoverageTraceCmp;
+CoverageFeatures |= CoverageTracePCGuard | CoverageIndirCall |
+CoverageTraceCmp | CoveragePCTable;
 
   Kinds |= Add;
 } else if (Arg->getOption().matches(options::OPT_fno_sanitize_EQ)) {

Modified: cfe/trunk/test/Driver/fuzzer.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fuzzer.c?rev=310136&r1=310135&r2=310136&view=diff
==
--- cfe/trunk/test/Driver/fuzzer.c (original)
+++ cfe/trunk/test/Driver/fuzzer.c Fri Aug  4 14:35:11 2017
@@ -6,6 +6,7 @@
 // CHECK-COVERAGE: -fsanitize-coverage-trace-pc-guard
 // CHECK-COVERAGE-SAME: -fsanitize-coverage-indirect-calls
 // CHECK-COVERAGE-SAME: -fsanitize-coverage-trace-cmp
+// CHECK-COVERAGE-SAME: -fsanitize-coverage-pc-table
 
 // RUN: %clang -fsanitize=fuzzer -target i386-unknown-linux -stdlib=platform 
%s -### 2>&1 | FileCheck --check-prefixes=CHECK-LIBCXX-LINUX %s
 //


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


r310409 - [sanitizer-coverage] -fsanitize-coverage=bb, inline-8bit-counters

2017-08-08 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Tue Aug  8 13:20:40 2017
New Revision: 310409

URL: http://llvm.org/viewvc/llvm-project?rev=310409&view=rev
Log:
[sanitizer-coverage] -fsanitize-coverage=bb,inline-8bit-counters

Modified:
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=310409&r1=310408&r2=310409&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Tue Aug  8 13:20:40 2017
@@ -543,8 +543,10 @@ SanitizerArgs::SanitizerArgs(const ToolC
 << "-fsanitize-coverage=trace-pc-guard";
 
   int InsertionPointTypes = CoverageFunc | CoverageBB | CoverageEdge;
+  int InstrumentationTypes =
+  CoverageTracePC | CoverageTracePCGuard | CoverageInline8bitCounters;
   if ((CoverageFeatures & InsertionPointTypes) &&
-  !(CoverageFeatures &(CoverageTracePC | CoverageTracePCGuard))) {
+  !(CoverageFeatures & InstrumentationTypes)) {
 D.Diag(clang::diag::warn_drv_deprecated_arg)
 << "-fsanitize-coverage=[func|bb|edge]"
 << "-fsanitize-coverage=[func|bb|edge],[trace-pc-guard|trace-pc]";

Modified: cfe/trunk/test/Driver/fsanitize-coverage.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize-coverage.c?rev=310409&r1=310408&r2=310409&view=diff
==
--- cfe/trunk/test/Driver/fsanitize-coverage.c (original)
+++ cfe/trunk/test/Driver/fsanitize-coverage.c Tue Aug  8 13:20:40 2017
@@ -86,6 +86,8 @@
 // CHECK_NOPRUNE: -fsanitize-coverage-no-prune
 
 // RUN: %clang -target x86_64-linux-gnu 
-fsanitize-coverage=inline-8bit-counters %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK_INLINE8BIT
+// RUN: %clang -target x86_64-linux-gnu 
-fsanitize-coverage=bb,inline-8bit-counters %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK_INLINE8BIT
+// CHECK_INLINE8BIT-NOT: warning
 // CHECK_INLINE8BIT: -fsanitize-coverage-inline-8bit-counters
 
 // RUN: %clang -target x86_64-linux-gnu 
-fsanitize-coverage=inline-8bit-counters,pc-table %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK_PC_TABLE


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


Re: r310408 - Integrate Kostya's clang-proto-fuzzer with LLVM.

2017-08-10 Thread Kostya Serebryany via cfe-commits
On Thu, Aug 10, 2017 at 10:56 AM, Nico Weber via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> I really believe this has way too many deps to live in the clang repro, as
> said on the review already.
>

I don't have a very strong opinion here and would be happy to move if I see
more support for Nico's opinion
(I haven't seen it on the review, and you didn't object further, so we
proceeded).
Again, my rational is that the simpler it is to use the more likely other
researchers will extend this work.

BTW, I am going to commit a Dockerfile that will make experimenting with
this trivial.
My current (dirty) version looks like this. Not too much trouble.

FROM ubuntu:16.04
RUN apt-get update -y && apt-get install -y autoconf automake libtool curl
make g++ unzip
RUN apt-get install -y wget
RUN apt-get install -y git binutils liblzma-dev libz-dev
RUN apt-get install -y python-all
RUN apt-get install -y cmake ninja-build
RUN apt-get install -y subversion

WORKDIR /root
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
RUN apt-get install -y pkg-config
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}')
RUN mkdir build0 && cd build0 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release
../llvm && ninja
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
RUN cd build1 && ninja clang-fuzzer
RUN cd build1 && ninja clang-proto-fuzzer
#RUN cd build1 && ninja clang-proto-to-cxx



> Maybe this could live in clang-extra instead?
>

clang-extra?
That's a separate repo, right?
It may require more cmake trickery, and we'll also have to share  the
clang-fuzzer-specific code between two repos.
I do want the original clang-fuzzer to remain where it was, and both
(clang-fuzzer and clang-proto-fuzzer) share the code.




>
> On Aug 8, 2017 4:15 PM, "Matt Morehouse via cfe-commits" <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: morehouse
>> Date: Tue Aug  8 13:15:04 2017
>> New Revision: 310408
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=310408&view=rev
>> Log:
>> Integrate Kostya's clang-proto-fuzzer with LLVM.
>>
>> Summary:
>> The clang-proto-fuzzer models a subset of C++ as a protobuf and
>> uses libprotobuf-mutator to generate interesting mutations of C++
>> programs.  Clang-proto-fuzzer has already found several bugs in
>> Clang (e.g., https://bugs.llvm.org/show_bug.cgi?id=33747,
>> https://bugs.llvm.org/show_bug.cgi?id=33749).
>>
>> As with clang-fuzzer, clang-proto-fuzzer requires the following
>> cmake flags:
>> - CMAKE_C_COMPILER=clang
>> - CMAKE_CXX_COMPILER=clang++
>> - LLVM_USE_SANITIZE_COVERAGE=YES  // needed for libFuzzer
>> - LLVM_USE_SANITIZER=Address  // needed for libFuzzer
>>
>> In addition, clang-proto-fuzzer requires:
>> - CLANG_ENABLE_PROTO_FUZZER=ON
>>
>> clang-proto-fuzzer also requires the following dependencies:
>> - binutils  // needed for libprotobuf-mutator
>> - liblzma-dev  // needed for libprotobuf-mutator
>> - libz-dev  // needed for libprotobuf-mutator
>> - docbook2x  // needed for libprotobuf-mutator
>> - Recent version of protobuf [3.3.0 is known to work]
>>
>> A working version of libprotobuf-mutator will automatically be
>> downloaded and built as an external project.
>>
>> Implementation of clang-proto-fuzzer provided by Kostya
>> Serebryany.
>>
>> https://bugs.llvm.org/show_bug.cgi?id=33829
>>
>> Reviewers: kcc, vitalybuka, bogner
>>
>> Reviewed By: kcc, vitalybuka
>>
>> Subscribers: thakis, mgorny, cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D36324
>>
>> Added:
>> cfe/trunk/cmake/modules/ProtobufMutator.cmake
>> cfe/trunk/tools/clang-fuzzer/ExampleClangProtoFuzzer.cpp
>> cfe/trunk/tools/clang-fuzzer/README.txt
>> cfe/trunk/tools/clang-fuzzer/cxx_proto.proto
>> cfe/trunk/tools/clang-fuzzer/handle-cxx/
>> cfe/trunk/tools/clang-fuzzer/handle-cxx/CMakeLists.txt
>> cfe/trunk/tools/clang-fuzzer/handle-cxx/handle_cxx.cpp
>> cfe/trunk/tools/clang-fuzzer/handle-cxx/handle_cxx.h
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/CMakeLists.txt
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.cpp
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.h
>> cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx_main.cpp
>> Modified:
>> cfe/trunk/CMakeList

Re: r310408 - Integrate Kostya's clang-proto-fuzzer with LLVM.

2017-08-10 Thread Kostya Serebryany via cfe-commits
On Thu, Aug 10, 2017 at 12:01 PM, Nico Weber  wrote:

> On Thu, Aug 10, 2017 at 2:04 PM, Kostya Serebryany  wrote:
>
>>
>>
>> On Thu, Aug 10, 2017 at 10:56 AM, Nico Weber via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> I really believe this has way too many deps to live in the clang repro,
>>> as said on the review already.
>>>
>>
>> I don't have a very strong opinion here and would be happy to move if I
>> see more support for Nico's opinion
>> (I haven't seen it on the review, and you didn't object further, so we
>> proceeded).
>> Again, my rational is that the simpler it is to use the more likely other
>> researchers will extend this work.
>>
>> BTW, I am going to commit a Dockerfile that will make experimenting with
>> this trivial.
>> My current (dirty) version looks like this. Not too much trouble.
>>
>> FROM ubuntu:16.04
>> RUN apt-get update -y && apt-get install -y autoconf automake libtool
>> curl make g++ unzip
>> RUN apt-get install -y wget
>> RUN apt-get install -y git binutils liblzma-dev libz-dev
>> RUN apt-get install -y python-all
>> RUN apt-get install -y cmake ninja-build
>> RUN apt-get install -y subversion
>>
>> WORKDIR /root
>> RUN wget -qO- https://github.com/google/prot
>> obuf/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
>> RUN apt-get install -y pkg-config
>> 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-proje
>> ct/compiler-rt/trunk clang -r $(cd ../ && svn info | grep Revision | awk
>> '{print $2}')
>> RUN mkdir build0 && cd build0 && cmake -GNinja -DCMAKE_BUILD_TYPE=Release
>> ../llvm && ninja
>> 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
>> RUN cd build1 && ninja clang-fuzzer
>> RUN cd build1 && ninja clang-proto-fuzzer
>> #RUN cd build1 && ninja clang-proto-to-cxx
>>
>>
>>
>>> Maybe this could live in clang-extra instead?
>>>
>>
>> clang-extra?
>>
>
> clang-tools-extra, sorry.
>
>
>> That's a separate repo, right?
>>
>
> Yes.
>
>
>> It may require more cmake trickery, and we'll also have to share  the
>> clang-fuzzer-specific code between two repos.
>>
>
> We could move the whole thing. I'd imagine that at most 3% of people who
> use clang will use this fuzzer, so having it elsewhere seems reasonable.
> (I'd imagine many more people to use clang-tidy for example, and that's in
> the other repro.)
>

The clang-tidy argument doesn't work for me.
clang-tidy is a separate tool.
clang*fuzzer are ways to test clang, and so they have more reasons to stay
closer to clang (for the same reason that the clang tests stay with clang).

--kcc


> Also see the "Contributing Extensions to Clang" section on
> http://clang.llvm.org/get_involved.html
>
>
>> I do want the original clang-fuzzer to remain where it was, and both
>> (clang-fuzzer and clang-proto-fuzzer) share the code.
>>
>>
>>
>>
>>>
>>> On Aug 8, 2017 4:15 PM, "Matt Morehouse via cfe-commits" <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: morehouse
 Date: Tue Aug  8 13:15:04 2017
 New Revision: 310408

 URL: http://llvm.org/viewvc/llvm-project?rev=310408&view=rev
 Log:
 Integrate Kostya's clang-proto-fuzzer with LLVM.

 Summary:
 The clang-proto-fuzzer models a subset of C++ as a protobuf and
 uses libprotobuf-mutator to generate interesting mutations of C++
 programs.  Clang-proto-fuzzer has already found several bugs in
 Clang (e.g., https://bugs.llvm.org/show_bug.cgi?id=33747,
 https://bugs.llvm.org/show_bug.cgi?id=33749).

 As with clang-fuzzer, clang-proto-fuzzer requires the following
 cmake flags:
 - CMAKE_C_COMPILER=clang
 - CMAKE_CXX_COMPILER=clang++
 - LLVM_USE_SANITIZE_COVERAGE=YES  // needed for libFuzzer
 - LLVM_USE_SANITIZER=Address  // needed for libFuzzer

 In addition, clang-proto-fuzzer requires:
 - CLANG_ENABLE_PROTO_FUZZER=ON

 clang-proto-fuzzer also requires the following dependencies:
 - binutils  // needed for libprotobuf-mutator
 - liblzma-dev  // needed for libprotobuf-mutator
 - libz-dev  // needed for libprotobuf-mutator
 - docbook2x  // needed for libprotobuf-mutator
 - Recent version of protobuf [3.3.0 is known to work]

 A working version of libprotobuf-mutator will automatically be
 downloaded and built as an external project.

 Implementation of clang-proto-fuzzer provided by Kostya
 Serebryany.

 

Re: r310408 - Integrate Kostya's clang-proto-fuzzer with LLVM.

2017-08-10 Thread Kostya Serebryany via cfe-commits
+klimek@ who contributed the first version of clang-fuzzer.
We now have clang-proto-fuzzer
(see tools/clang/tools/clang-fuzzer/README.txt)
which shares code with clang-fuzzer, but which also depends on various
packages (protobufs, in particular).
clang-proto-fuzzer is off by default (requires a cmake flag) so these extra
deps don't hurt anyone,
but Nico's concern is that this way we pollute the main repo with code that
requires extra deps.

We could probably move the code to another repo (clang-tools-extra?) but my
concerns are:

* this is extra work, I don't want to do it "just in case". Only if it's a
common agreement that the change will improve the overall state enough to
spend this time.

* we need to keep clang-fuzzer together with clang-proto-fuzzer, they are
too close to have them separately.
But this will make clang-fuzzer even less used.  (Admittedly, the bugs
found by clang-fuzzer are not being fixed anyway)

WDYT?

--kcc





On Thu, Aug 10, 2017 at 12:32 PM, Nico Weber  wrote:

> On Thu, Aug 10, 2017 at 3:13 PM, Kostya Serebryany  wrote:
>
>>
>>
>> On Thu, Aug 10, 2017 at 12:01 PM, Nico Weber  wrote:
>>
>>> On Thu, Aug 10, 2017 at 2:04 PM, Kostya Serebryany 
>>> wrote:
>>>


 On Thu, Aug 10, 2017 at 10:56 AM, Nico Weber via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> I really believe this has way too many deps to live in the clang
> repro, as said on the review already.
>

 I don't have a very strong opinion here and would be happy to move if I
 see more support for Nico's opinion
 (I haven't seen it on the review, and you didn't object further, so we
 proceeded).
 Again, my rational is that the simpler it is to use the more likely
 other researchers will extend this work.

 BTW, I am going to commit a Dockerfile that will make experimenting
 with this trivial.
 My current (dirty) version looks like this. Not too much trouble.

 FROM ubuntu:16.04
 RUN apt-get update -y && apt-get install -y autoconf automake libtool
 curl make g++ unzip
 RUN apt-get install -y wget
 RUN apt-get install -y git binutils liblzma-dev libz-dev
 RUN apt-get install -y python-all
 RUN apt-get install -y cmake ninja-build
 RUN apt-get install -y subversion

 WORKDIR /root
 RUN wget -qO- https://github.com/google/prot
 obuf/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
 RUN apt-get install -y pkg-config
 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-proje
 ct/compiler-rt/trunk clang -r $(cd ../ && svn info | grep Revision |
 awk '{print $2}')
 RUN mkdir build0 && cd build0 && cmake -GNinja
 -DCMAKE_BUILD_TYPE=Release ../llvm && ninja
 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
 RUN cd build1 && ninja clang-fuzzer
 RUN cd build1 && ninja clang-proto-fuzzer
 #RUN cd build1 && ninja clang-proto-to-cxx



> Maybe this could live in clang-extra instead?
>

 clang-extra?

>>>
>>> clang-tools-extra, sorry.
>>>
>>>
 That's a separate repo, right?

>>>
>>> Yes.
>>>
>>>
 It may require more cmake trickery, and we'll also have to share  the
 clang-fuzzer-specific code between two repos.

>>>
>>> We could move the whole thing. I'd imagine that at most 3% of people who
>>> use clang will use this fuzzer, so having it elsewhere seems reasonable.
>>> (I'd imagine many more people to use clang-tidy for example, and that's in
>>> the other repro.)
>>>
>>
>> The clang-tidy argument doesn't work for me.
>> clang-tidy is a separate tool.
>> clang*fuzzer are ways to test clang, and so they have more reasons to
>> stay closer to clang (for the same reason that the clang tests stay with
>> clang).
>>
>
> Then think of the "[cfe-dev] Proposal for an ABI testsuite for clang"
> thread instead, which was about testing clang. We ended up putting that
> into a completely separate repo.
>
>
>
>
>>
>> --kcc
>>
>>
>>> Also see the "Contributing Extensions to Clang" section on
>>> http://clang.llvm.org/get_involved.html
>>>
>>>
 I do want the original clang-fuzzer to remain where it was, and both
 (clang-fuzzer and clang-proto-fuzzer) share the code.




>
> On Aug 8, 2017 4:15 PM, "Matt Morehouse via cfe-commits" <
> cfe-commits@lists.llvm.org> wr

r310774 - Add a Dockerfile for clang-proto-fuzzer

2017-08-11 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Fri Aug 11 18:27:10 2017
New Revision: 310774

URL: http://llvm.org/viewvc/llvm-project?rev=310774&view=rev
Log:
Add a Dockerfile for clang-proto-fuzzer

Summary: Add a Dockerfile for clang-proto-fuzzer

Reviewers: morehouse, vitalybuka

Reviewed By: morehouse

Subscribers: hintonda, cfe-commits

Differential Revision: https://reviews.llvm.org/D36635

Added:
cfe/trunk/tools/clang-fuzzer/Dockerfile
Modified:
cfe/trunk/tools/clang-fuzzer/README.txt

Added: cfe/trunk/tools/clang-fuzzer/Dockerfile
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-fuzzer/Dockerfile?rev=310774&view=auto
==
--- cfe/trunk/tools/clang-fuzzer/Dockerfile (added)
+++ cfe/trunk/tools/clang-fuzzer/Dockerfile Fri Aug 11 18:27:10 2017
@@ -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

Modified: cfe/trunk/tools/clang-fuzzer/README.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-fuzzer/README.txt?rev=310774&r1=310773&r2=310774&view=diff
==
--- cfe/trunk/tools/clang-fuzzer/README.txt (original)
+++ cfe/trunk/tools/clang-fuzzer/README.txt Fri Aug 11 18:27:10 2017
@@ -59,6 +59,8 @@ Example:
 -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


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


r311719 - [sanitizer-coverage] document -fsanitize-coverage=pc-table and -fsanitize-coverage=inline-8bit-counters

2017-08-24 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Thu Aug 24 15:40:03 2017
New Revision: 311719

URL: http://llvm.org/viewvc/llvm-project?rev=311719&view=rev
Log:
[sanitizer-coverage] document -fsanitize-coverage=pc-table and 
-fsanitize-coverage=inline-8bit-counters

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=311719&r1=311718&r2=311719&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Thu Aug 24 15:40:03 2017
@@ -119,6 +119,51 @@ Example:
   guard: 0x71bcdc 4 PC 0x4ecdc7 in main trace-pc-guard-example.cc:4:17
   guard: 0x71bcd0 1 PC 0x4ecd20 in foo() trace-pc-guard-example.cc:2:14
 
+Inline 8bit-counters
+
+
+**Experimental, may change or disappear in future**
+
+With ``-fsanitize-coverage=inline-8bit-counters`` the compiler will insert
+inline counter increments on every edge.
+This is similar to ``-fsanitize-coverage=trace-pc-guard`` but instead of a
+callback the instrumentation simply increments a counter.
+
+Users need to implement a single function to capture the counters at startup.
+
+.. code-block:: c++
+
+  extern "C"
+  void __sanitizer_cov_8bit_counters_init(char *start, char *end) {
+// [start,end) is the array of 8-bit counters created for the current DSO.
+// Capture this array in order to read/modify the counters.
+  }
+
+PC-Table
+
+
+**Experimental, may change or disappear in future**
+
+With ``-fsanitize-coverage=pc-table`` the compiler will create a table of
+instrumented PCs. Requires either ``-fsanitize-coverage=inline-8bit-counters`` 
or
+``-fsanitize-coverage=trace-pc-guard``.
+
+Users need to implement a single function to capture the counters at startup:
+
+.. code-block:: c++
+
+  extern "C"
+  void __sanitizer_cov_pcs_init(const uint8_t *pcs_beg,
+const uint8_t *pcs_end) {
+// [pcs_beg,pcs_end) is the array of ptr-sized integers representing
+// PCs of the instrumented blocks in the current DSO.
+// Capture this array in order to read the PCs.
+// The number of PCs for a given DSO is the same as the number of
+// 8-bit counters (-fsanitize-coverage=inline-8bit-counters) or
+// trace_pc_guard callbacks (-fsanitize-coverage=trace-pc-guard)
+  }
+
+
 Tracing PCs
 ===
 
@@ -131,7 +176,6 @@ by the user.
 This mechanism is used for fuzzing the Linux kernel
 (https://github.com/google/syzkaller).
 
-
 Instrumentation points
 ==
 Sanitizer Coverage offers different levels of instrumentation.


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


Re: [clang] 0e3a487 - PR12350: Handle remaining cases permitted by CWG DR 244.

2020-02-12 Thread Kostya Serebryany via cfe-commits
Could this have caused a new ubsan failure?

clang/lib/AST/NestedNameSpecifier.cpp:485:23: runtime error: null
pointer passed as argument 2, which is declared to never be null

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/38698/steps/check-clang%20ubsan/logs/stdio

On Fri, Feb 7, 2020 at 6:41 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Richard Smith
> Date: 2020-02-07T18:40:41-08:00
> New Revision: 0e3a48778408b505946e465abf5c77a2ddd4918c
>
> URL:
> https://github.com/llvm/llvm-project/commit/0e3a48778408b505946e465abf5c77a2ddd4918c
> DIFF:
> https://github.com/llvm/llvm-project/commit/0e3a48778408b505946e465abf5c77a2ddd4918c.diff
>
> LOG: PR12350: Handle remaining cases permitted by CWG DR 244.
>
> Also add extension warnings for the cases that are disallowed by the
> current rules for destructor name lookup, refactor and simplify the
> lookup code, and improve the diagnostic quality when lookup fails.
>
> The special case we previously supported for converting
> p->N::S::~S() from naming a class template into naming a
> specialization thereof is subsumed by a more general rule here (which is
> also consistent with Clang's historical behavior and that of other
> compilers): if we can't find a suitable S in N, also look in N::S.
>
> The extension warnings are off by default, except for a warning when
> lookup for p->N::S::~T() looks for T in scope instead of in N (or N::S).
> That seems sufficiently heinous to warn on by default, especially since
> we can't support it for a dependent nested-name-specifier.
>
> Added:
>
>
> Modified:
> clang/include/clang/Basic/DiagnosticGroups.td
> clang/include/clang/Basic/DiagnosticSemaKinds.td
> clang/lib/AST/NestedNameSpecifier.cpp
> clang/lib/Sema/DeclSpec.cpp
> clang/lib/Sema/SemaExprCXX.cpp
> clang/test/CXX/class/class.mem/p13.cpp
> clang/test/CXX/drs/dr2xx.cpp
> clang/test/CXX/drs/dr3xx.cpp
> clang/test/FixIt/fixit.cpp
> clang/test/Parser/cxx-decl.cpp
> clang/test/SemaCXX/constructor.cpp
> clang/test/SemaCXX/destructor.cpp
> clang/test/SemaCXX/pseudo-destructors.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/include/clang/Basic/DiagnosticGroups.td
> b/clang/include/clang/Basic/DiagnosticGroups.td
> index a2bc29986a07..8c54723cdbab 100644
> --- a/clang/include/clang/Basic/DiagnosticGroups.td
> +++ b/clang/include/clang/Basic/DiagnosticGroups.td
> @@ -192,6 +192,7 @@ def CXX2aDesignator : DiagGroup<"c++2a-designator">;
>  // designators (including the warning controlled by -Wc++2a-designator).
>  def C99Designator : DiagGroup<"c99-designator", [CXX2aDesignator]>;
>  def GNUDesignator : DiagGroup<"gnu-designator">;
> +def DtorName : DiagGroup<"dtor-name">;
>
>  def DynamicExceptionSpec
>  : DiagGroup<"dynamic-exception-spec",
> [DeprecatedDynamicExceptionSpec]>;
>
> diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
> b/clang/include/clang/Basic/DiagnosticSemaKinds.td
> index 9de60d3a8d27..82861f0d5d72 100644
> --- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
> +++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
> @@ -1911,17 +1911,33 @@ def err_destructor_with_params : Error<"destructor
> cannot have any parameters">;
>  def err_destructor_variadic : Error<"destructor cannot be variadic">;
>  def err_destructor_typedef_name : Error<
>"destructor cannot be declared using a %select{typedef|type alias}1 %0
> of the class name">;
> +def err_undeclared_destructor_name : Error<
> +  "undeclared identifier %0 in destructor name">;
>  def err_destructor_name : Error<
>"expected the class name after '~' to name the enclosing class">;
> -def err_destructor_class_name : Error<
> -  "expected the class name after '~' to name a destructor">;
> -def err_ident_in_dtor_not_a_type : Error<
> +def err_destructor_name_nontype : Error<
> +  "identifier %0 after '~' in destructor name does not name a type">;
> +def err_destructor_expr_mismatch : Error<
> +  "identifier %0 in object destruction expression does not name the type "
> +  "%1 of the object being destroyed">;
> +def err_destructor_expr_nontype : Error<
>"identifier %0 in object destruction expression does not name a type">;
>  def err_destructor_expr_type_mismatch : Error<
>"destructor type %0 in object destruction expression does not match the
> "
>"type %1 of the object being destroyed">;
>  def note_destructor_type_here : Note<
> -  "type %0 is declared here">;
> +  "type %0 found by destructor name lookup">;
> +def note_destructor_nontype_here : Note<
> +  "non-type declaration found by destructor name lookup">;
> +def ext_dtor_named_in_wrong_scope : Extension<
> +  "ISO C++ requires the name after '::~' to be found in the same scope as
> "
> +  "the name before '::~'">, InGroup;
> +def ext_dtor_name_missing_template_arguments : Extension<
> +  "ISO C++ requires template argument list

[libcxxabi] r290650 - add cxa_demangle_fuzzer

2016-12-27 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Tue Dec 27 21:28:29 2016
New Revision: 290650

URL: http://llvm.org/viewvc/llvm-project?rev=290650&view=rev
Log:
add cxa_demangle_fuzzer

Summary:
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

Reviewers: compnerd, mclow.lists, mehdi_amini

Subscribers: cfe-commits, mgorny

Differential Revision: https://reviews.llvm.org/D28133

Added:
libcxxabi/trunk/fuzz/
libcxxabi/trunk/fuzz/CMakeLists.txt
libcxxabi/trunk/fuzz/cxa_demangle_fuzzer.cpp
Modified:
libcxxabi/trunk/CMakeLists.txt

Modified: libcxxabi/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/CMakeLists.txt?rev=290650&r1=290649&r2=290650&view=diff
==
--- libcxxabi/trunk/CMakeLists.txt (original)
+++ libcxxabi/trunk/CMakeLists.txt Tue Dec 27 21:28:29 2016
@@ -432,4 +432,5 @@ if (LIBCXXABI_STANDALONE_BUILD AND NOT L
   "available!")
 else()
   add_subdirectory(test)
+  add_subdirectory(fuzz)
 endif()

Added: libcxxabi/trunk/fuzz/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/fuzz/CMakeLists.txt?rev=290650&view=auto
==
--- libcxxabi/trunk/fuzz/CMakeLists.txt (added)
+++ libcxxabi/trunk/fuzz/CMakeLists.txt Tue Dec 27 21:28:29 2016
@@ -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()

Added: libcxxabi/trunk/fuzz/cxa_demangle_fuzzer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/fuzz/cxa_demangle_fuzzer.cpp?rev=290650&view=auto
==
--- libcxxabi/trunk/fuzz/cxa_demangle_fuzzer.cpp (added)
+++ libcxxabi/trunk/fuzz/cxa_demangle_fuzzer.cpp Tue Dec 27 21:28:29 2016
@@ -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;
+}


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


r279028 - [sanitizer-coverag] update the docs in __sanitizer_cov_trace_cmp

2016-08-17 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Wed Aug 17 20:26:36 2016
New Revision: 279028

URL: http://llvm.org/viewvc/llvm-project?rev=279028&view=rev
Log:
[sanitizer-coverag] update the docs in __sanitizer_cov_trace_cmp

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=279028&r1=279027&r2=279028&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Wed Aug 17 20:26:36 2016
@@ -333,11 +333,11 @@ they will be called by the instrumented
 .. code-block:: c++
 
   // Called before a comparison instruction.
-  // SizeAndType is a packed value containing
-  //   - [63:32] the Size of the operands of comparison in bits
-  //   - [31:0] the Type of comparison (one of ICMP_EQ, ... ICMP_SLE)
   // Arg1 and Arg2 are arguments of the comparison.
-  void __sanitizer_cov_trace_cmp(uint64_t SizeAndType, uint64_t Arg1, uint64_t 
Arg2);
+  void __sanitizer_cov_trace_cmp1(uint8_t Arg1, uint8_t Arg2);
+  void __sanitizer_cov_trace_cmp2(uint16_t Arg1, uint16_t Arg2);
+  void __sanitizer_cov_trace_cmp4(uint32_t Arg1, uint32_t Arg2);
+  void __sanitizer_cov_trace_cmp8(uint64_t Arg1, uint64_t Arg2);
 
   // Called before a switch statement.
   // Val is the switch operand.


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


r280044 - [sanitizer-coverage] add two more modes of instrumentation: trace-div and trace-gep, mostly usaful for value-profile-based fuzzing; clang part

2016-08-29 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Mon Aug 29 20:27:03 2016
New Revision: 280044

URL: http://llvm.org/viewvc/llvm-project?rev=280044&view=rev
Log:
[sanitizer-coverage] add two more modes of instrumentation: trace-div and 
trace-gep, mostly usaful for value-profile-based fuzzing; clang part

Modified:
cfe/trunk/docs/SanitizerCoverage.rst
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=280044&r1=280043&r2=280044&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Mon Aug 29 20:27:03 2016
@@ -324,11 +324,14 @@ and can be used with `AFL `_
+(to capture array indices).
 
 .. code-block:: c++
 
@@ -346,6 +349,16 @@ they will be called by the instrumented
   // Cases[2:] are the case constants.
   void __sanitizer_cov_trace_switch(uint64_t Val, uint64_t *Cases);
 
+  // Called before a division statement.
+  // Val is the second argument of division.
+  void __sanitizer_cov_trace_div4(uint32_t Val);
+  void __sanitizer_cov_trace_div8(uint64_t Val);
+
+  // Called before a GetElemementPtr (GEP) instruction
+  // for every non-constant array index.
+  void __sanitizer_cov_trace_gep(uintptr_t Idx);
+
+
 This interface is a subject to change.
 The current implementation is not thread-safe and thus can be safely used only 
for single-threaded targets.
 

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=280044&r1=280043&r2=280044&view=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Mon Aug 29 20:27:03 2016
@@ -272,6 +272,12 @@ def fsanitize_coverage_trace_bb
 def fsanitize_coverage_trace_cmp
 : Flag<["-"], "fsanitize-coverage-trace-cmp">,
   HelpText<"Enable cmp instruction tracing in sanitizer coverage">;
+def fsanitize_coverage_trace_div
+: Flag<["-"], "fsanitize-coverage-trace-div">,
+  HelpText<"Enable div instruction tracing in sanitizer coverage">;
+def fsanitize_coverage_trace_gep
+: Flag<["-"], "fsanitize-coverage-trace-gep">,
+  HelpText<"Enable gep instruction tracing in sanitizer coverage">;
 def fsanitize_coverage_8bit_counters
 : Flag<["-"], "fsanitize-coverage-8bit-counters">,
   HelpText<"Enable frequency counters in sanitizer coverage">;

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=280044&r1=280043&r2=280044&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Mon Aug 29 20:27:03 2016
@@ -151,6 +151,10 @@ CODEGENOPT(SanitizeCoverageTraceBB, 1, 0
   ///< in sanitizer coverage.
 CODEGENOPT(SanitizeCoverageTraceCmp, 1, 0) ///< Enable cmp instruction tracing
///< in sanitizer coverage.
+CODEGENOPT(SanitizeCoverageTraceDiv, 1, 0) ///< Enable div instruction tracing
+   ///< in sanitizer coverage.
+CODEGENOPT(SanitizeCoverageTraceGep, 1, 0) ///< Enable GEP instruction tracing
+   ///< in sanitizer coverage.
 CODEGENOPT(SanitizeCoverage8bitCounters, 1, 0) ///< Use 8-bit frequency 
counters
///< in sanitizer coverage.
 CODEGENOPT(SanitizeCoverageTracePC, 1, 0) ///< Enable PC tracing

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=280044&r1=280043&r2=280044&view=diff
==

Re: [PATCH] D24048: [Driver] [Darwin] Add sanitizer libraries even if -nodefaultlibs is passed

2016-09-01 Thread Kostya Serebryany via cfe-commits
kcc added reviewers: vitalybuka, eugenis.
kcc added a comment.

Sorry, I won't have a chance to look at it before late next week. 
Adding two more folks in case they have ideas.


https://reviews.llvm.org/D24048



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


r281432 - [sanitizer-coverage] add yet another flavour of coverage instrumentation: trace-pc-guard. The intent is to eventually replace all of {bool coverage, 8bit-counters, trace-pc} with just this o

2016-09-13 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Tue Sep 13 20:39:49 2016
New Revision: 281432

URL: http://llvm.org/viewvc/llvm-project?rev=281432&view=rev
Log:
[sanitizer-coverage] add yet another flavour of coverage instrumentation: 
trace-pc-guard. The intent is to eventually replace all of {bool coverage, 
8bit-counters, trace-pc} with just this one. Clang part

Modified:
cfe/trunk/docs/SanitizerCoverage.rst
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=281432&r1=281431&r2=281432&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Tue Sep 13 20:39:49 2016
@@ -321,6 +321,32 @@ by the user. So, these flags do not requ
 This mechanism is used for fuzzing the Linux kernel 
(https://github.com/google/syzkaller)
 and can be used with `AFL `__.
 
+Tracing PCs with guards
+===
+Another *experimental* feature that tries to combine `trace-pc`,
+`8bit-counters` and boolean coverage
+
+With ``-fsanitize-coverage=trace-pc-guard`` the compiler will insert the 
following code
+on every edge:
+
+.. code-block:: none
+
+   if (guard_variable != 0xff)
+ __sanitizer_cov_trace_pc_guard(&guard_variable)
+
+Every edge will have its own 1-byte `guard_variable`.
+All such guard variables will reside in a dedicated section
+(i.e. they essentially form an array).
+
+The compler will also insert a module constructor that will call
+
+.. code-block:: c++
+
+   // The guard section is the address range [start, stop).
+   __sanitizer_cov_trace_pc_guard_init(void *start, void *stop);
+
+The functions `__sanitizer_cov_trace_pc_guard[_init]` should be defined by the 
user.
+
 Tracing data flow
 =
 

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=281432&r1=281431&r2=281432&view=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Tue Sep 13 20:39:49 2016
@@ -289,6 +289,9 @@ def fsanitize_coverage_8bit_counters
 def fsanitize_coverage_trace_pc
 : Flag<["-"], "fsanitize-coverage-trace-pc">,
   HelpText<"Enable PC tracing in sanitizer coverage">;
+def fsanitize_coverage_trace_pc_guard
+: Flag<["-"], "fsanitize-coverage-trace-pc-guard">,
+  HelpText<"Enable PC tracing with guard in sanitizer coverage">;
 def fprofile_instrument_EQ : Joined<["-"], "fprofile-instrument=">,
 HelpText<"Enable PGO instrumentation. The accepted value is clang, llvm, "
  "or none">;

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=281432&r1=281431&r2=281432&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Tue Sep 13 20:39:49 2016
@@ -160,6 +160,8 @@ CODEGENOPT(SanitizeCoverage8bitCounters,
///< in sanitizer coverage.
 CODEGENOPT(SanitizeCoverageTracePC, 1, 0) ///< Enable PC tracing
   ///< in sanitizer coverage.
+CODEGENOPT(SanitizeCoverageTracePCGuard, 1, 0) ///< Enable PC tracing with 
guard
+   ///< in sanitizer coverage.
 CODEGENOPT(SanitizeStats , 1, 0) ///< Collect statistics for sanitizers.
 CODEGENOPT(SimplifyLibCalls  , 1, 1) ///< Set when -fbuiltin is enabled.
 CODEGENOPT(SoftFloat , 1, 0) ///< -soft-float.

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=281432&r1=281431&r2=281432&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Tue Sep 13 20:39:49 2016
@@ -180,6 +180,7 @@ static void addSanitizerCoveragePass(con
   Opts.TraceGep = CGOpts.SanitizeCoverageTraceGep;
   Opts.Use8bitCounters = CGOpts.SanitizeCoverage8bitCounters;
   Opts.TracePC = CGOpts.SanitizeCoverageTracePC;
+  Opts.TracePCGuard = CGOpts.SanitizeCoverageTracePCGuard;
   PM.add(createSanitizerCoverageModulePass(Opts));
 }
 

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=2

r281665 - [sanitizer-coverage] make trace-pc-guard and indirect-call work together

2016-09-15 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Thu Sep 15 17:11:08 2016
New Revision: 281665

URL: http://llvm.org/viewvc/llvm-project?rev=281665&view=rev
Log:
[sanitizer-coverage] make trace-pc-guard and indirect-call work together

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=281665&r1=281664&r2=281665&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Thu Sep 15 17:11:08 2016
@@ -323,8 +323,8 @@ and can be used with `AFL 

Re: [PATCH] D24640: [CUDA] Don't try to run sanitizers on NVPTX.

2016-09-15 Thread Kostya Serebryany 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/D24640



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


r281809 - [sanitizer-coverage] change trace-pc to use 8-byte guards

2016-09-16 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Sat Sep 17 00:03:05 2016
New Revision: 281809

URL: http://llvm.org/viewvc/llvm-project?rev=281809&view=rev
Log:
[sanitizer-coverage] change trace-pc to use 8-byte guards

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=281809&r1=281808&r2=281809&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Sat Sep 17 00:03:05 2016
@@ -331,24 +331,23 @@ on every edge:
 
 .. code-block:: none
 
-   if (guard_variable != 0xff)
+   if (guard_variable >= 0)
  __sanitizer_cov_trace_pc_guard(&guard_variable)
 
-Every edge will have its own 1-byte `guard_variable`.
-All such guard variables will reside in a dedicated section
-(i.e. they essentially form an array).
-
-Similarly to `trace-pc,indirect-calls`, with `trace-pc-guards,indirect-calls`
-``__sanitizer_cov_trace_pc_indirect(void *callee)`` will be inserted on every 
indirect call.
+Every edge will have its own 8-byte `guard_variable`.
 
 The compler will also insert a module constructor that will call
 
 .. code-block:: c++
 
-   // The guard section is the address range [start, stop).
-   __sanitizer_cov_trace_pc_guard_init(void *start, void *stop);
+   // The guards are [start, stop).
+   // This function may be called multiple times with the same values of 
start/stop.
+   __sanitizer_cov_trace_pc_guard_init(uint64_t *start, uint64_t *stop);
+
+Similarly to `trace-pc,indirect-calls`, with `trace-pc-guards,indirect-calls`
+``__sanitizer_cov_trace_pc_indirect(void *callee)`` will be inserted on every 
indirect call.
 
-The functions `__sanitizer_cov_trace_pc_guard[_init]` should be defined by the 
user.
+The functions `__sanitizer_cov_trace_pc_*` should be defined by the user.
 
 Tracing data flow
 =


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


r298303 - Proposal: Backward-edge CFI for return statements (RCFI)

2017-03-20 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Mon Mar 20 15:42:00 2017
New Revision: 298303

URL: http://llvm.org/viewvc/llvm-project?rev=298303&view=rev
Log:
Proposal: Backward-edge CFI for return statements (RCFI)

Summary: Proposal: Backward-edge CFI for return statements (RCFI)

Reviewers: pcc, eugenis, krasin

Reviewed By: eugenis

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D31112

Modified:
cfe/trunk/docs/ControlFlowIntegrityDesign.rst

Modified: cfe/trunk/docs/ControlFlowIntegrityDesign.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ControlFlowIntegrityDesign.rst?rev=298303&r1=298302&r2=298303&view=diff
==
--- cfe/trunk/docs/ControlFlowIntegrityDesign.rst (original)
+++ cfe/trunk/docs/ControlFlowIntegrityDesign.rst Mon Mar 20 15:42:00 2017
@@ -498,12 +498,100 @@ In non-PIE executables the address of an
 the main executable) is the address of that function’s PLT record in
 the main executable. This would break the CFI checks.
 
+Backward-edge CFI for return statements (RCFI)
+==
+
+This section is a proposal. As of March 2017 it is not implemented.
+
+Backward-edge control flow (`RET` instructions) can be hijacked
+via overwriting the return address (`RA`) on stack.
+Various mitigation techniques (e.g. `SafeStack`_, `RFG`_, `Intel CET`_)
+try to detect or prevent `RA` corruption on stack.
+
+RCFI enforces the expected control flow in several different ways described 
below.
+RCFI heavily relies on LTO.
+
+Leaf Functions
+--
+If `f()` is a leaf function (i.e. it has no calls
+except maybe no-return calls) it can be called using a special calling 
convention
+that stores `RA` in a dedicated register `R` before the `CALL` instruction.
+`f()` does not spill `R` and does not use the `RET` instruction,
+instead it uses the value in `R` to `JMP` to `RA`.
+
+This flavour of CFI is *precise*, i.e. the function is guaranteed to return
+to the point exactly following the call.
+
+An alternative approach is to
+copy `RA` from stack to `R` in the first instruction of `f()`,
+then `JMP` to `R`.
+This approach is simpler to implement (does not require changing the caller)
+but weaker (there is a small window when `RA` is actually stored on stack).
+
+
+Functions called once
+-
+Suppose `f()` is called in just one place in the program
+(assuming we can verify this in LTO mode).
+In this case we can replace the `RET` instruction with a `JMP` instruction
+with the immediate constant for `RA`.
+This will *precisely* enforce the return control flow no matter what is stored 
on stack.
+
+Another variant is to compare `RA` on stack with the known constant and abort
+if they don't match; then `JMP` to the known constant address.
+
+Functions called in a small number of call sites
+
+We may extend the above approach to cases where `f()`
+is called more than once (but still a small number of times).
+With LTO we know all possible values of `RA` and we check them
+one-by-one (or using binary search) against the value on stack.
+If the match is found, we `JMP` to the known constant address, otherwise abort.
+
+This protection is *near-precise*, i.e. it guarantees that the control flow 
will
+be transferred to one of the valid return addresses for this function,
+but not necessary to the point of the most recent `CALL`.
+
+General case
+
+For functions called multiple times a *return jump table* is constructed
+in the same manner as jump tables for indirect function calls (see above).
+The correct jump table entry (or it's index) is passed by `CALL` to `f()`
+(as an extra argument) and then spilled to stack.
+The `RET` instruction is replaced with a load of the jump table entry,
+jump table range check, and `JMP` to the jump table entry.
+
+This protection is also *near-precise*.
+
+Returns from functions called indirectly
+
+
+If a function is called indirectly, the return jump table is constructed for 
the
+equivalence class of functions instead of a single function.
+
+Cross-DSO calls
+---
+Consider two instrumented DSOs, `A` and `B`. `A` defines `f()` and `B` calls 
it.
+
+This case will be handled similarly to the cross-DSO scheme using the slow 
path callback.
+
+Non-goals
+-
+
+RCFI does not protect `RET` instructions:
+  * in non-instrumented DSOs,
+  * in instrumented DSOs for functions that are called from non-instrumented 
DSOs,
+  * embedded into other instructions (e.g. `0f4fc3 cmovg %ebx,%eax`).
+
+.. _SafeStack: https://clang.llvm.org/docs/SafeStack.html
+.. _RFG: http://xlab.tencent.com/en/2016/11/02/return-flow-guard
+.. _Intel CET: 
https://software.intel.com/en-us/blogs/2016/06/09/intel-release-new-technology-specifications-protect-rop-attacks
 
 Hardware support
 
 
 We believe that the above design ca

r292862 - [sanitizer-coverage] emit __sanitizer_cov_trace_pc_guard w/o a preceding 'if' by default. Update the docs, also add deprecation notes around other parts of sanitizer coverage

2017-01-23 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Mon Jan 23 18:57:31 2017
New Revision: 292862

URL: http://llvm.org/viewvc/llvm-project?rev=292862&view=rev
Log:
[sanitizer-coverage] emit __sanitizer_cov_trace_pc_guard w/o a preceding 'if' 
by default. Update the docs, also add deprecation notes around other parts of 
sanitizer coverage

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=292862&r1=292861&r2=292862&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Mon Jan 23 18:57:31 2017
@@ -227,7 +227,8 @@ easily used for bitset-based corpus dist
 Caller-callee coverage
 ==
 
-(Experimental!)
+**Deprecated, don't use**
+
 Every indirect function call is instrumented with a run-time function call that
 captures caller and callee.  At the shutdown time the process dumps a separate
 file called ``caller-callee.PID.sancov`` which contains caller/callee pairs as
@@ -253,6 +254,8 @@ Current limitations:
 Coverage counters
 =
 
+**Deprecated, don't use**
+
 This experimental feature is inspired by
 `AFL `__'s coverage
 instrumentation. With additional compile-time and run-time flags you can get
@@ -296,6 +299,9 @@ These counters may also be used for in-p
 
 Tracing basic blocks
 
+
+**Deprecated, don't use**
+
 Experimental support for basic block (or edge) tracing.
 With ``-fsanitize-coverage=trace-bb`` the compiler will insert
 ``__sanitizer_cov_trace_basic_block(s32 *id)`` before every function, basic 
block, or edge
@@ -319,6 +325,9 @@ Basic block tracing is currently support
 
 Tracing PCs
 ===
+
+**Deprecated, don't use**
+
 *Experimental* feature similar to tracing basic blocks, but with a different 
API.
 With ``-fsanitize-coverage=trace-pc`` the compiler will insert
 ``__sanitizer_cov_trace_pc()`` on every edge.
@@ -331,16 +340,13 @@ and can be used with `AFL 

r308045 - do more processing in clang-fuzzer (use EmitAssemblyAction)

2017-07-14 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Fri Jul 14 11:42:07 2017
New Revision: 308045

URL: http://llvm.org/viewvc/llvm-project?rev=308045&view=rev
Log:
do more processing in clang-fuzzer (use EmitAssemblyAction)

Summary: use EmitAssemblyAction in clang-fuzzer

Reviewers: klimek, rsmith

Reviewed By: klimek

Subscribers: cfe-commits, mgorny

Differential Revision: https://reviews.llvm.org/D34267

Modified:
cfe/trunk/tools/clang-fuzzer/CMakeLists.txt
cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp

Modified: cfe/trunk/tools/clang-fuzzer/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-fuzzer/CMakeLists.txt?rev=308045&r1=308044&r2=308045&view=diff
==
--- cfe/trunk/tools/clang-fuzzer/CMakeLists.txt (original)
+++ cfe/trunk/tools/clang-fuzzer/CMakeLists.txt Fri Jul 14 11:42:07 2017
@@ -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 @@ if( LLVM_USE_SANITIZE_COVERAGE )
 ${CLANG_FORMAT_LIB_DEPS}
 clangAST
 clangBasic
+clangCodeGen
 clangDriver
 clangFrontend
 clangRewriteFrontend

Modified: cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp?rev=308045&r1=308044&r2=308045&view=diff
==
--- cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp (original)
+++ cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp Fri Jul 14 11:42:07 2017
@@ -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 @@ extern "C" int LLVMFuzzerTestOneInput(ui
   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,


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


Re: r309036 - [StaticAnalyzer] LoopUnrolling - Attempt to fix a crash in r309006.

2017-07-25 Thread Kostya Serebryany via cfe-commits
Looks like one more failure (this time under ubsan) remains in this code
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/6708/steps/check-clang%20ubsan/logs/stdio
Please fix asap.

/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/StaticAnalyzer/Core/LoopUnrolling.cpp:188:45:
runtime error: member call on null pointer of type
'clang::LocationContext'
#0 0x6aa767d in clang::ento::isUnrolledLoopBlock(clang::CFGBlock
const*, clang::ento::ExplodedNode*, clang::ento::AnalysisManager&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/StaticAnalyzer/Core/LoopUnrolling.cpp:188:45
#1 0x6a651ed in
clang::ento::ExprEngine::processCFGBlockEntrance(clang::BlockEdge
const&, clang::ento::NodeBuilderWithSinks&,
clang::ento::ExplodedNode*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:1519:9
#2 0x6a401a0 in
clang::ento::CoreEngine::HandleBlockEdge(clang::BlockEdge const&,
clang::ento::ExplodedNode*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:334:10
#3 0x6a3fd33 in
clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode*,
clang::ProgramPoint, clang::ento::WorkListUnit const&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:246:7
#4 0x6a3f97b in
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext
const*, unsigned int,
llvm::IntrusiveRefCntPtr)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:235:5
#5 0x53edd9e in
clang::ento::ExprEngine::ExecuteWorkList(clang::LocationContext
const*, unsigned int)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h:109:19
#6 0x539ac8e in (anonymous
namespace)::AnalysisConsumer::ActionExprEngine(clang::Decl*, bool,
clang::ento::ExprEngine::InliningModes, llvm::DenseSet >*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:717:7
#7 0x539a478 in (anonymous
namespace)::AnalysisConsumer::HandleCode(clang::Decl*, unsigned int,
clang::ento::ExprEngine::InliningModes, llvm::DenseSet >*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:685:5
#8 0x538e22d in (anonymous
namespace)::AnalysisConsumer::HandleDeclsCallGraph(unsigned int)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:498:5
#9 0x538bb29 in (anonymous
namespace)::AnalysisConsumer::HandleTranslationUnit(clang::ASTContext&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:550:7
#10 0x5462b99 in clang::ParseAST(clang::Sema&, bool, bool)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseAST.cpp:159:13
#11 0x3fc98f2 in clang::FrontendAction::Execute()
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:902:8
#12 0x3f57d74 in
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:980:11
#13 0x415a1ac in
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:251:25
#14 0xe8a5fe in cc1_main(llvm::ArrayRef, char const*,
void*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/tools/driver/cc1_main.cpp:221:13
#15 0xe7ca13 in ExecuteCC1Tool(llvm::ArrayRef,
llvm::StringRef)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/cla


On Tue, Jul 25, 2017 at 2:54 PM, Peter Szecsi via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: szepet
> Date: Tue Jul 25 14:54:58 2017
> New Revision: 309036
>
> URL: http://llvm.org/viewvc/llvm-project?rev=309036&view=rev
> Log:
> [StaticAnalyzer] LoopUnrolling - Attempt to fix a crash in r309006.
>
>
> Modified:
> cfe/trunk/lib/StaticAnalyzer/Core/LoopUnrolling.cpp
>
> Modified: cfe/trunk/lib/StaticAnalyzer/Core/LoopUnrolling.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/
> StaticAnalyzer/Core/LoopUnrolling.cpp?rev=309036&
> r1=309035&r2=309036&view=diff
> 
> ==
> --- cfe/trunk/lib/StaticAnalyzer/Core/LoopUnrolling.cpp (original)
> +++ cfe/trunk/lib/StaticAnalyzer/Core/LoopUnrolling.cpp Tue Jul 25
> 14:54:58 2017
> @@ -183,8 +183,10 @@ bool isUnrolledLoopBlock(const CFGBlock
>  LBV.

r309338 - [sanitizer-coverage] clang flags pumbing for -fsanitize-coverage=pc-table

2017-07-27 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Thu Jul 27 17:10:10 2017
New Revision: 309338

URL: http://llvm.org/viewvc/llvm-project?rev=309338&view=rev
Log:
[sanitizer-coverage] clang flags pumbing for -fsanitize-coverage=pc-table

Modified:
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=309338&r1=309337&r2=309338&view=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Thu Jul 27 17:10:10 2017
@@ -295,6 +295,9 @@ def fsanitize_coverage_8bit_counters
 def fsanitize_coverage_inline_8bit_counters
 : Flag<["-"], "fsanitize-coverage-inline-8bit-counters">,
   HelpText<"Enable inline 8-bit counters in sanitizer coverage">;
+def fsanitize_coverage_pc_table
+: Flag<["-"], "fsanitize-coverage-pc-table">,
+  HelpText<"Create a table of coverage-instrumented PCs">;
 def fsanitize_coverage_trace_pc
 : Flag<["-"], "fsanitize-coverage-trace-pc">,
   HelpText<"Enable PC tracing in sanitizer coverage">;

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=309338&r1=309337&r2=309338&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Thu Jul 27 17:10:10 2017
@@ -167,6 +167,7 @@ CODEGENOPT(SanitizeCoverageTracePC, 1, 0
 CODEGENOPT(SanitizeCoverageTracePCGuard, 1, 0) ///< Enable PC tracing with 
guard
///< in sanitizer coverage.
 CODEGENOPT(SanitizeCoverageInline8bitCounters, 1, 0) ///< Use inline 8bit 
counters.
+CODEGENOPT(SanitizeCoveragePCTable, 1, 0) ///< Create a PC Table.
 CODEGENOPT(SanitizeCoverageNoPrune, 1, 0) ///< Disable coverage pruning.
 CODEGENOPT(SanitizeStats , 1, 0) ///< Collect statistics for sanitizers.
 CODEGENOPT(SimplifyLibCalls  , 1, 1) ///< Set when -fbuiltin is enabled.

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=309338&r1=309337&r2=309338&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Thu Jul 27 17:10:10 2017
@@ -189,6 +189,7 @@ static void addSanitizerCoveragePass(con
   Opts.TracePCGuard = CGOpts.SanitizeCoverageTracePCGuard;
   Opts.NoPrune = CGOpts.SanitizeCoverageNoPrune;
   Opts.Inline8bitCounters = CGOpts.SanitizeCoverageInline8bitCounters;
+  Opts.PCTable = CGOpts.SanitizeCoveragePCTable;
   PM.add(createSanitizerCoverageModulePass(Opts));
 }
 

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=309338&r1=309337&r2=309338&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Thu Jul 27 17:10:10 2017
@@ -55,8 +55,9 @@ enum CoverageFeature {
   Coverage8bitCounters = 1 << 8,  // Deprecated.
   CoverageTracePC = 1 << 9,
   CoverageTracePCGuard = 1 << 10,
-  CoverageInline8bitCounters = 1 << 12,
   CoverageNoPrune = 1 << 11,
+  CoverageInline8bitCounters = 1 << 12,
+  CoveragePCTable = 1 << 13,
 };
 
 /// Parse a -fsanitize= or -fno-sanitize= argument's values, diagnosing any
@@ -663,6 +664,7 @@ void SanitizerArgs::addArgs(const ToolCh
 std::make_pair(CoverageTracePC, "-fsanitize-coverage-trace-pc"),
 std::make_pair(CoverageTracePCGuard, "-fsanitize-coverage-trace-pc-guard"),
 std::make_pair(CoverageInline8bitCounters, 
"-fsanitize-coverage-inline-8bit-counters"),
+std::make_pair(CoveragePCTable, "-fsanitize-coverage-pc-table"),
 std::make_pair(CoverageNoPrune, "-fsanitize-coverage-no-prune")};
   for (auto F : CoverageFlags) {
 if (CoverageFeatures & F.first)
@@ -825,6 +827,7 @@ int parseCoverageFeatures(const Driver &
 .Case("trace-pc-guard", CoverageTracePCGuard)
 .Case("no-prune", CoverageNoPrune)
 .Case("inline-8bit-counters", CoverageInline8bitCounters)
+.Case("pc-table", CoveragePCTable)
 .Default(0);
 if (F == 0)
   D.Diag(clang::diag::err_drv_unsupported_option_argument)

Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=309338&r1=309337&r2=309338&view=di

[PATCH] D26763: [compiler-rt] [asan] Use __SSE2__ (rather than __i686__...) for SSE2 test

2016-11-17 Thread Kostya Serebryany via cfe-commits
kcc accepted this revision.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM, 
assuming you have verified that the test is still executed.


https://reviews.llvm.org/D26763



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


r300738 - [sanitizer-coverage] deprecate some of the stale coverage variants

2017-04-19 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Wed Apr 19 14:57:16 2017
New Revision: 300738

URL: http://llvm.org/viewvc/llvm-project?rev=300738&view=rev
Log:
[sanitizer-coverage] deprecate some of the stale coverage variants

Modified:
cfe/trunk/docs/SanitizerCoverage.rst
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=300738&r1=300737&r2=300738&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Wed Apr 19 14:57:16 2017
@@ -202,27 +202,7 @@ edges by introducing new dummy blocks an
 Bitset
 ==
 
-When ``coverage_bitset=1`` run-time flag is given, the coverage will also be
-dumped as a bitset (text file with 1 for blocks that have been executed and 0
-for blocks that were not).
-
-.. code-block:: console
-
-% clang++ -fsanitize=address -fsanitize-coverage=edge cov.cc
-% ASAN_OPTIONS="coverage=1:coverage_bitset=1" ./a.out
-main
-% ASAN_OPTIONS="coverage=1:coverage_bitset=1" ./a.out 1
-foo
-main
-% head *bitset*
-==> a.out.38214.bitset-sancov <==
-01101
-==> a.out.6128.bitset-sancov <==
-11011%
-
-For a given executable the length of the bitset is always the same (well,
-unless dlopen/dlclose come into play), so the bitset coverage can be
-easily used for bitset-based corpus distillation.
+**coverage_bitset=1 is deprecated, don't use**
 
 Caller-callee coverage
 ==
@@ -326,8 +306,6 @@ Basic block tracing is currently support
 Tracing PCs
 ===
 
-**Deprecated, don't use**
-
 *Experimental* feature similar to tracing basic blocks, but with a different 
API.
 With ``-fsanitize-coverage=trace-pc`` the compiler will insert
 ``__sanitizer_cov_trace_pc()`` on every edge.

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=300738&r1=300737&r2=300738&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Wed Apr 19 14:57:16 2017
@@ -469,34 +469,12 @@ SanitizerArgs::SanitizerArgs(const ToolC
   int LegacySanitizeCoverage;
   if (Arg->getNumValues() == 1 &&
   !StringRef(Arg->getValue(0))
-   .getAsInteger(0, LegacySanitizeCoverage) &&
-  LegacySanitizeCoverage >= 0 && LegacySanitizeCoverage <= 4) {
-switch (LegacySanitizeCoverage) {
-case 0:
-  CoverageFeatures = 0;
-  Arg->claim();
-  break;
-case 1:
-  D.Diag(diag::warn_drv_deprecated_arg) << Arg->getAsString(Args)
-<< "-fsanitize-coverage=func";
-  CoverageFeatures = CoverageFunc;
-  break;
-case 2:
-  D.Diag(diag::warn_drv_deprecated_arg) << Arg->getAsString(Args)
-<< "-fsanitize-coverage=bb";
-  CoverageFeatures = CoverageBB;
-  break;
-case 3:
-  D.Diag(diag::warn_drv_deprecated_arg) << Arg->getAsString(Args)
-<< "-fsanitize-coverage=edge";
-  CoverageFeatures = CoverageEdge;
-  break;
-case 4:
+   .getAsInteger(0, LegacySanitizeCoverage)) {
+CoverageFeatures = 0;
+Arg->claim();
+if (LegacySanitizeCoverage != 0) {
   D.Diag(diag::warn_drv_deprecated_arg)
-  << Arg->getAsString(Args)
-  << "-fsanitize-coverage=edge,indirect-calls";
-  CoverageFeatures = CoverageEdge | CoverageIndirCall;
-  break;
+  << Arg->getAsString(Args) << 
"-fsanitize-coverage=trace-pc-guard";
 }
 continue;
   }

Modified: cfe/trunk/test/Driver/fsanitize-coverage.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize-coverage.c?rev=300738&r1=300737&r2=300738&view=diff
==
--- cfe/trunk/test/Driver/fsanitize-coverage.c (original)
+++ cfe/trunk/test/Driver/fsanitize-coverage.c Wed Apr 19 14:57:16 2017
@@ -23,14 +23,7 @@
 // CHECK-SANITIZE-COVERAGE-FUNC_INDIR: fsanitize-coverage-indirect-calls
 
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=1 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-1
-// CHECK-SANITIZE-COVERAGE-1: warning: argument '-fsanitize-coverage=1' is 
deprecated, use '-fsanitize-coverage=func' instead
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=2 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-2
-// CHECK-SANITIZE-COVERAGE-2: warning: argument '-fsanitize-coverage=2' is 
deprecated, u

r300744 - [sanitizer-coverage] deprecate -fsanitize-coverage=8bit-counters

2017-04-19 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Wed Apr 19 15:15:58 2017
New Revision: 300744

URL: http://llvm.org/viewvc/llvm-project?rev=300744&view=rev
Log:
[sanitizer-coverage] deprecate -fsanitize-coverage=8bit-counters

Modified:
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=300744&r1=300743&r2=300744&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Wed Apr 19 15:15:58 2017
@@ -513,11 +513,10 @@ SanitizerArgs::SanitizerArgs(const ToolC
 D.Diag(clang::diag::err_drv_argument_only_allowed_with)
 << "-fsanitize-coverage=trace-bb"
 << "-fsanitize-coverage=(func|bb|edge)";
-  if ((CoverageFeatures & Coverage8bitCounters) &&
-  !(CoverageFeatures & CoverageTypes))
-D.Diag(clang::diag::err_drv_argument_only_allowed_with)
+  if ((CoverageFeatures & Coverage8bitCounters))
+D.Diag(clang::diag::warn_drv_deprecated_arg)
 << "-fsanitize-coverage=8bit-counters"
-<< "-fsanitize-coverage=(func|bb|edge)";
+<< "-fsanitize-coverage=trace-pc-guard";
   // trace-pc w/o func/bb/edge implies edge.
   if ((CoverageFeatures & (CoverageTracePC | CoverageTracePCGuard)) &&
   !(CoverageFeatures & CoverageTypes))

Modified: cfe/trunk/test/Driver/fsanitize-coverage.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize-coverage.c?rev=300744&r1=300743&r2=300744&view=diff
==
--- cfe/trunk/test/Driver/fsanitize-coverage.c (original)
+++ cfe/trunk/test/Driver/fsanitize-coverage.c Wed Apr 19 15:15:58 2017
@@ -33,14 +33,13 @@
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=func -fno-sanitize=address %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-SAN-DISABLED
 // CHECK-SANITIZE-COVERAGE-SAN-DISABLED-NOT: argument unused
 
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=edge,indirect-calls,trace-bb,trace-pc,trace-cmp,8bit-counters,trace-div,trace-gep
 %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANITIZE-COVERAGE-FEATURES
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=edge,indirect-calls,trace-bb,trace-pc,trace-cmp,trace-div,trace-gep
 %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANITIZE-COVERAGE-FEATURES
 // CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-type=3
 // CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-indirect-calls
 // CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-trace-bb
 // CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-trace-cmp
 // CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-trace-div
 // CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-trace-gep
-// CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-8bit-counters
 // CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-trace-pc
 
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=func,edge,indirect-calls,trace-bb,trace-cmp 
-fno-sanitize-coverage=edge,indirect-calls,trace-bb %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-MASK
@@ -54,8 +53,8 @@
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=func -fsanitize-coverage=edge %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-INCOMPATIBLE
 // CHECK-INCOMPATIBLE: error: invalid argument '-fsanitize-coverage=func' not 
allowed with '-fsanitize-coverage=edge'
 
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=8bit-counters %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-MISSING-TYPE
-// CHECK-MISSING-TYPE: error: invalid argument 
'-fsanitize-coverage=8bit-counters' only allowed with 
'-fsanitize-coverage=(func|bb|edge)'
+// RUN: %clang -target x86_64-linux-gnu -fsanitize-coverage=8bit-counters %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-8BIT
+// CHECK-8BIT: warning: argument '-fsanitize-coverage=8bit-counters' is 
deprecated, use '-fsanitize-coverage=trace-pc-guard' instead
 
 // RUN: %clang -target x86_64-linux-gnu -fsanitize-coverage=trace-pc %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-TRACE_PC_EDGE
 // RUN: %clang -target x86_64-linux-gnu -fsanitize-coverage=edge,trace-pc %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-TRACE_PC_EDGE


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


r300755 - Fix a leak in tools/driver/cc1as_main.cpp

2017-04-19 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Wed Apr 19 15:57:13 2017
New Revision: 300755

URL: http://llvm.org/viewvc/llvm-project?rev=300755&view=rev
Log:
Fix a leak in tools/driver/cc1as_main.cpp

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

Reviewers: pcc

Reviewed By: pcc

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D32243

Modified:
cfe/trunk/tools/driver/cc1as_main.cpp

Modified: cfe/trunk/tools/driver/cc1as_main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/cc1as_main.cpp?rev=300755&r1=300754&r2=300755&view=diff
==
--- cfe/trunk/tools/driver/cc1as_main.cpp (original)
+++ cfe/trunk/tools/driver/cc1as_main.cpp Wed Apr 19 15:57:13 2017
@@ -506,12 +506,12 @@ int cc1as_main(ArrayRef Ar
   // 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


r300767 - [sanitizer-coverage] deprecate -fsanitize-coverage=trace-bb

2017-04-19 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Wed Apr 19 16:31:11 2017
New Revision: 300767

URL: http://llvm.org/viewvc/llvm-project?rev=300767&view=rev
Log:
[sanitizer-coverage] deprecate -fsanitize-coverage=trace-bb

Modified:
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=300767&r1=300766&r2=300767&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Wed Apr 19 16:31:11 2017
@@ -508,12 +508,11 @@ SanitizerArgs::SanitizerArgs(const ToolC
   // Basic block tracing and 8-bit counters require some type of coverage
   // enabled.
   int CoverageTypes = CoverageFunc | CoverageBB | CoverageEdge;
-  if ((CoverageFeatures & CoverageTraceBB) &&
-  !(CoverageFeatures & CoverageTypes))
-D.Diag(clang::diag::err_drv_argument_only_allowed_with)
+  if (CoverageFeatures & CoverageTraceBB)
+D.Diag(clang::diag::warn_drv_deprecated_arg)
 << "-fsanitize-coverage=trace-bb"
-<< "-fsanitize-coverage=(func|bb|edge)";
-  if ((CoverageFeatures & Coverage8bitCounters))
+<< "-fsanitize-coverage=trace-pc-guard";
+  if (CoverageFeatures & Coverage8bitCounters)
 D.Diag(clang::diag::warn_drv_deprecated_arg)
 << "-fsanitize-coverage=8bit-counters"
 << "-fsanitize-coverage=trace-pc-guard";

Modified: cfe/trunk/test/Driver/fsanitize-coverage.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize-coverage.c?rev=300767&r1=300766&r2=300767&view=diff
==
--- cfe/trunk/test/Driver/fsanitize-coverage.c (original)
+++ cfe/trunk/test/Driver/fsanitize-coverage.c Wed Apr 19 16:31:11 2017
@@ -33,16 +33,15 @@
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=func -fno-sanitize=address %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-SAN-DISABLED
 // CHECK-SANITIZE-COVERAGE-SAN-DISABLED-NOT: argument unused
 
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=edge,indirect-calls,trace-bb,trace-pc,trace-cmp,trace-div,trace-gep
 %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANITIZE-COVERAGE-FEATURES
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=edge,indirect-calls,trace-pc,trace-cmp,trace-div,trace-gep 
%s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANITIZE-COVERAGE-FEATURES
 // CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-type=3
 // CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-indirect-calls
-// CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-trace-bb
 // CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-trace-cmp
 // CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-trace-div
 // CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-trace-gep
 // CHECK-SANITIZE-COVERAGE-FEATURES: -fsanitize-coverage-trace-pc
 
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=func,edge,indirect-calls,trace-bb,trace-cmp 
-fno-sanitize-coverage=edge,indirect-calls,trace-bb %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-MASK
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=func,edge,indirect-calls,trace-cmp 
-fno-sanitize-coverage=edge,indirect-calls %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-MASK
 // CHECK-MASK: -fsanitize-coverage-type=1
 // CHECK-MASK: -fsanitize-coverage-trace-cmp
 // CHECK-MASK-NOT: -fsanitize-coverage-
@@ -55,6 +54,8 @@
 
 // RUN: %clang -target x86_64-linux-gnu -fsanitize-coverage=8bit-counters %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-8BIT
 // CHECK-8BIT: warning: argument '-fsanitize-coverage=8bit-counters' is 
deprecated, use '-fsanitize-coverage=trace-pc-guard' instead
+// RUN: %clang -target x86_64-linux-gnu -fsanitize-coverage=trace-bb %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-TRACE-BB
+// CHECK-TRACE-BB: warning: argument '-fsanitize-coverage=trace-bb' is 
deprecated, use '-fsanitize-coverage=trace-pc-guard' instead
 
 // RUN: %clang -target x86_64-linux-gnu -fsanitize-coverage=trace-pc %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-TRACE_PC_EDGE
 // RUN: %clang -target x86_64-linux-gnu -fsanitize-coverage=edge,trace-pc %s 
-### 2>&1 | FileCheck %s --check-prefix=CHECK-TRACE_PC_EDGE


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


r300776 - [sanitizer-coverage] trim down the docs

2017-04-19 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Wed Apr 19 17:25:30 2017
New Revision: 300776

URL: http://llvm.org/viewvc/llvm-project?rev=300776&view=rev
Log:
[sanitizer-coverage] trim down the docs

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=300776&r1=300775&r2=300776&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Wed Apr 19 17:25:30 2017
@@ -25,17 +25,10 @@ following compile-time flags:
   **extra** slowdown).
 * ``-fsanitize-coverage=edge`` for edge-level coverage (up to 40% slowdown).
 
-You may also specify ``-fsanitize-coverage=indirect-calls`` for
-additional `caller-callee coverage`_.
-
 At run time, pass ``coverage=1`` in ``ASAN_OPTIONS``,
 ``LSAN_OPTIONS``, ``MSAN_OPTIONS`` or ``UBSAN_OPTIONS``, as
 appropriate. For the standalone coverage mode, use ``UBSAN_OPTIONS``.
 
-To get `Coverage counters`_, add ``-fsanitize-coverage=8bit-counters``
-to one of the above compile-time flags. At runtime, use
-``*SAN_OPTIONS=coverage=1:coverage_counters=1``.
-
 Example:
 
 .. code-block:: console
@@ -199,110 +192,6 @@ edges by introducing new dummy blocks an
 |/
 C
 
-Bitset
-==
-
-**coverage_bitset=1 is deprecated, don't use**
-
-Caller-callee coverage
-==
-
-**Deprecated, don't use**
-
-Every indirect function call is instrumented with a run-time function call that
-captures caller and callee.  At the shutdown time the process dumps a separate
-file called ``caller-callee.PID.sancov`` which contains caller/callee pairs as
-pairs of lines (odd lines are callers, even lines are callees)
-
-.. code-block:: console
-
-a.out 0x4a2e0c
-a.out 0x4a6510
-a.out 0x4a2e0c
-a.out 0x4a87f0
-
-Current limitations:
-
-* Only the first 14 callees for every caller are recorded, the rest are 
silently
-  ignored.
-* The output format is not very compact since caller and callee may reside in
-  different modules and we need to spell out the module names.
-* The routine that dumps the output is not optimized for speed
-* Only Linux x86_64 is tested so far.
-* Sandboxes are not supported.
-
-Coverage counters
-=
-
-**Deprecated, don't use**
-
-This experimental feature is inspired by
-`AFL `__'s coverage
-instrumentation. With additional compile-time and run-time flags you can get
-more sensitive coverage information.  In addition to boolean values assigned to
-every basic block (edge) the instrumentation will collect imprecise counters.
-On exit, every counter will be mapped to a 8-bit bitset representing counter
-ranges: ``1, 2, 3, 4-7, 8-15, 16-31, 32-127, 128+`` and those 8-bit bitsets 
will
-be dumped to disk.
-
-.. code-block:: console
-
-% clang++ -g cov.cc -fsanitize=address 
-fsanitize-coverage=edge,8bit-counters
-% ASAN_OPTIONS="coverage=1:coverage_counters=1" ./a.out
-% ls -l *counters-sancov
-... a.out.17110.counters-sancov
-% xxd *counters-sancov
-000: 0001 0100 01
-
-These counters may also be used for in-process coverage-guided fuzzers. See
-``include/sanitizer/coverage_interface.h``:
-
-.. code-block:: c++
-
-// The coverage instrumentation may optionally provide imprecise counters.
-// Rather than exposing the counter values to the user we instead map
-// the counters to a bitset.
-// Every counter is associated with 8 bits in the bitset.
-// We define 8 value ranges: 1, 2, 3, 4-7, 8-15, 16-31, 32-127, 128+
-// The i-th bit is set to 1 if the counter value is in the i-th range.
-// This counter-based coverage implementation is *not* thread-safe.
-
-// Returns the number of registered coverage counters.
-uintptr_t __sanitizer_get_number_of_counters();
-// Updates the counter 'bitset', clears the counters and returns the 
number of
-// new bits in 'bitset'.
-// If 'bitset' is nullptr, only clears the counters.
-// Otherwise 'bitset' should be at least
-// __sanitizer_get_number_of_counters bytes long and 8-aligned.
-uintptr_t
-__sanitizer_update_counter_bitset_and_clear_counters(uint8_t *bitset);
-
-Tracing basic blocks
-
-
-**Deprecated, don't use**
-
-Experimental support for basic block (or edge) tracing.
-With ``-fsanitize-coverage=trace-bb`` the compiler will insert
-``__sanitizer_cov_trace_basic_block(s32 *id)`` before every function, basic 
block, or edge
-(depending on the value of ``-fsanitize-coverage=[func,bb,edge]``).
-Example:
-
-.. code-block:: console
-
-% clang -g -fsanitize=address -fsanitize-coverage=edge,trace-bb foo.cc
-% ASAN_OPTIONS=coverage=1 ./a.out
-
-This will produce two files after the process exit:
-`trace-points.PID.sancov` and `trace-events.PID.sancov`.
-The first file will contain a textual description of al

r301824 - [sanitizer-coverage] add a deprecation note to coverage_direct=1

2017-05-01 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Mon May  1 14:52:01 2017
New Revision: 301824

URL: http://llvm.org/viewvc/llvm-project?rev=301824&view=rev
Log:
[sanitizer-coverage] add a deprecation note to coverage_direct=1

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=301824&r1=301823&r2=301824&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Mon May  1 14:52:01 2017
@@ -367,6 +367,8 @@ This can be changed with ``ASAN_OPTIONS=
 Sudden death
 
 
+*Deprecated, don't use*
+
 Normally, coverage data is collected in memory and saved to disk when the
 program exits (with an ``atexit()`` handler), when a SIGSEGV is caught, or when
 ``__sanitizer_cov_dump()`` is called.


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


r301888 - [sanitizer-coverage] update the SanitizerCoverage docs to reflect the current state

2017-05-01 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Mon May  1 19:32:57 2017
New Revision: 301888

URL: http://llvm.org/viewvc/llvm-project?rev=301888&view=rev
Log:
[sanitizer-coverage] update the SanitizerCoverage docs to reflect the current 
state

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=301888&r1=301887&r2=301888&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Mon May  1 19:32:57 2017
@@ -8,202 +8,12 @@ SanitizerCoverage
 Introduction
 
 
-Sanitizer tools have a very simple code coverage tool built in. It allows to
-get function-level, basic-block-level, and edge-level coverage at a very low
-cost.
-
-How to build and run
-
-
-SanitizerCoverage can be used with :doc:`AddressSanitizer`,
-:doc:`LeakSanitizer`, :doc:`MemorySanitizer`,
-UndefinedBehaviorSanitizer, or without any sanitizer.  Pass one of the
-following compile-time flags:
-
-* ``-fsanitize-coverage=func`` for function-level coverage (very fast).
-* ``-fsanitize-coverage=bb`` for basic-block-level coverage (may add up to 30%
-  **extra** slowdown).
-* ``-fsanitize-coverage=edge`` for edge-level coverage (up to 40% slowdown).
-
-At run time, pass ``coverage=1`` in ``ASAN_OPTIONS``,
-``LSAN_OPTIONS``, ``MSAN_OPTIONS`` or ``UBSAN_OPTIONS``, as
-appropriate. For the standalone coverage mode, use ``UBSAN_OPTIONS``.
-
-Example:
-
-.. code-block:: console
-
-% cat -n cov.cc
- 1  #include 
- 2  __attribute__((noinline))
- 3  void foo() { printf("foo\n"); }
- 4
- 5  int main(int argc, char **argv) {
- 6if (argc == 2)
- 7  foo();
- 8printf("main\n");
- 9  }
-% clang++ -g cov.cc -fsanitize=address -fsanitize-coverage=func
-% ASAN_OPTIONS=coverage=1 ./a.out; ls -l *sancov
-main
--rw-r- 1 kcc eng 4 Nov 27 12:21 a.out.22673.sancov
-% ASAN_OPTIONS=coverage=1 ./a.out foo ; ls -l *sancov
-foo
-main
--rw-r- 1 kcc eng 4 Nov 27 12:21 a.out.22673.sancov
--rw-r- 1 kcc eng 8 Nov 27 12:21 a.out.22679.sancov
-
-Every time you run an executable instrumented with SanitizerCoverage
-one ``*.sancov`` file is created during the process shutdown.
-If the executable is dynamically linked against instrumented DSOs,
-one ``*.sancov`` file will be also created for every DSO.
-
-Postprocessing
-==
-
-The format of ``*.sancov`` files is very simple: the first 8 bytes is the 
magic,
-one of ``0xC0BFFF64`` and ``0xC0BFFF32``. The last byte of the
-magic defines the size of the following offsets. The rest of the data is the
-offsets in the corresponding binary/DSO that were executed during the run.
-
-A simple script
-``$LLVM/projects/compiler-rt/lib/sanitizer_common/scripts/sancov.py`` is
-provided to dump these offsets.
-
-.. code-block:: console
-
-% sancov.py print a.out.22679.sancov a.out.22673.sancov
-sancov.py: read 2 PCs from a.out.22679.sancov
-sancov.py: read 1 PCs from a.out.22673.sancov
-sancov.py: 2 files merged; 2 PCs total
-0x465250
-0x4652a0
-
-You can then filter the output of ``sancov.py`` through ``addr2line --exe
-ObjectFile`` or ``llvm-symbolizer --obj ObjectFile`` to get file names and line
-numbers:
-
-.. code-block:: console
-
-% sancov.py print a.out.22679.sancov a.out.22673.sancov 2> /dev/null | 
llvm-symbolizer --obj a.out
-cov.cc:3
-cov.cc:5
-
-Sancov Tool
-===
-
-A new experimental ``sancov`` tool is developed to process coverage files.
-The tool is part of LLVM project and is currently supported only on Linux.
-It can handle symbolization tasks autonomously without any extra support
-from the environment. You need to pass .sancov files (named 
-``..sancov`` and paths to all corresponding binary elf 
files. 
-Sancov matches these files using module names and binaries file names.
-
-.. code-block:: console
-
-USAGE: sancov [options]  (|<.sancov file>)...
-
-Action (required)
-  -print- Print coverage addresses
-  -covered-functions- Print all covered functions.
-  -not-covered-functions- Print all not covered functions.
-  -symbolize- Symbolizes the report.
-
-Options
-  -blacklist= - Blacklist file (sanitizer blacklist 
format).
-  -demangle   - Print demangled function name.
-  -strip_path_prefix= - Strip this prefix from file paths in 
reports
-
-
-Coverage Reports (Experimental)
-
-
-``.sancov`` files do not contain enough information to generate a source-level 
-coverage report. The missing information is contained
-in debug info of the binary. Thus the ``.sancov`` has to be symbolized
-to produce a ``.symcov`` file first:
-
-.. code-bl

r301994 - [sanitizer-coverage] add a deprecation warning to the old sanitizer-coverage flag combinations

2017-05-02 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Tue May  2 20:27:28 2017
New Revision: 301994

URL: http://llvm.org/viewvc/llvm-project?rev=301994&view=rev
Log:
[sanitizer-coverage] add a deprecation warning to the old sanitizer-coverage 
flag combinations

Modified:
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=301994&r1=301993&r2=301994&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Tue May  2 20:27:28 2017
@@ -511,7 +511,6 @@ SanitizerArgs::SanitizerArgs(const ToolC
 << "-fsanitize-coverage=edge";
   // Basic block tracing and 8-bit counters require some type of coverage
   // enabled.
-  int CoverageTypes = CoverageFunc | CoverageBB | CoverageEdge;
   if (CoverageFeatures & CoverageTraceBB)
 D.Diag(clang::diag::warn_drv_deprecated_arg)
 << "-fsanitize-coverage=trace-bb"
@@ -520,9 +519,18 @@ SanitizerArgs::SanitizerArgs(const ToolC
 D.Diag(clang::diag::warn_drv_deprecated_arg)
 << "-fsanitize-coverage=8bit-counters"
 << "-fsanitize-coverage=trace-pc-guard";
+
+  int InsertionPointTypes = CoverageFunc | CoverageBB | CoverageEdge;
+  if ((CoverageFeatures & InsertionPointTypes) &&
+  !(CoverageFeatures &(CoverageTracePC | CoverageTracePCGuard))) {
+D.Diag(clang::diag::warn_drv_deprecated_arg)
+<< "-fsanitize-coverage=[func|bb|edge]"
+<< "-fsanitize-coverage=[func|bb|edge],[trace-pc-guard|trace-pc]";
+  }
+
   // trace-pc w/o func/bb/edge implies edge.
   if ((CoverageFeatures & (CoverageTracePC | CoverageTracePCGuard)) &&
-  !(CoverageFeatures & CoverageTypes))
+  !(CoverageFeatures & InsertionPointTypes))
 CoverageFeatures |= CoverageEdge;
 
   if (AllAddedKinds & Address) {

Modified: cfe/trunk/test/Driver/fsanitize-coverage.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize-coverage.c?rev=301994&r1=301993&r2=301994&view=diff
==
--- cfe/trunk/test/Driver/fsanitize-coverage.c (original)
+++ cfe/trunk/test/Driver/fsanitize-coverage.c Tue May  2 20:27:28 2017
@@ -4,12 +4,13 @@
 // CHECK-SANITIZE-COVERAGE-0-NOT: fsanitize-coverage-type
 // CHECK-SANITIZE-COVERAGE-0: -fsanitize=address
 
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=leak 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=bool 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=dataflow 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=func,trace-pc %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory 
-fsanitize-coverage=func,trace-pc %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=leak 
-fsanitize-coverage=func,trace-pc %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined 
-fsanitize-coverage=func,trace-pc %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=bool 
-fsanitize-coverage=func,trace-pc %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=dataflow 
-fsanitize-coverage=func,trace-pc %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
+// RUN: %clang -target x86_64-linux-gnu 
-fsanitize-coverage=func,trace-pc %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
 // CHECK-SANITIZE-COVERAGE-FUNC: fsanitize-coverage-type=1
 
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=bb %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-BB
@@ -25,13 +26,10 @@
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=1 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-1

Re: r301994 - [sanitizer-coverage] add a deprecation warning to the old sanitizer-coverage flag combinations

2017-05-03 Thread Kostya Serebryany via cfe-commits
Thanks!

On Wed, May 3, 2017 at 9:15 AM, Reid Kleckner  wrote:

> This broke a WinASan test that builds with -Werror:
> http://lab.llvm.org:8011/builders/sanitizer-windows/builds/10647
>
> I tried to fix it in r302043, but I haven't finished testing it yet.
>
> On Tue, May 2, 2017 at 6:27 PM, Kostya Serebryany via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: kcc
>> Date: Tue May  2 20:27:28 2017
>> New Revision: 301994
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=301994&view=rev
>> Log:
>> [sanitizer-coverage] add a deprecation warning to the old
>> sanitizer-coverage flag combinations
>>
>> Modified:
>> cfe/trunk/lib/Driver/SanitizerArgs.cpp
>> cfe/trunk/test/Driver/fsanitize-coverage.c
>>
>> Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/San
>> itizerArgs.cpp?rev=301994&r1=301993&r2=301994&view=diff
>> 
>> ==
>> --- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
>> +++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Tue May  2 20:27:28 2017
>> @@ -511,7 +511,6 @@ SanitizerArgs::SanitizerArgs(const ToolC
>>  << "-fsanitize-coverage=edge";
>>// Basic block tracing and 8-bit counters require some type of coverage
>>// enabled.
>> -  int CoverageTypes = CoverageFunc | CoverageBB | CoverageEdge;
>>if (CoverageFeatures & CoverageTraceBB)
>>  D.Diag(clang::diag::warn_drv_deprecated_arg)
>>  << "-fsanitize-coverage=trace-bb"
>> @@ -520,9 +519,18 @@ SanitizerArgs::SanitizerArgs(const ToolC
>>  D.Diag(clang::diag::warn_drv_deprecated_arg)
>>  << "-fsanitize-coverage=8bit-counters"
>>  << "-fsanitize-coverage=trace-pc-guard";
>> +
>> +  int InsertionPointTypes = CoverageFunc | CoverageBB | CoverageEdge;
>> +  if ((CoverageFeatures & InsertionPointTypes) &&
>> +  !(CoverageFeatures &(CoverageTracePC | CoverageTracePCGuard))) {
>> +D.Diag(clang::diag::warn_drv_deprecated_arg)
>> +<< "-fsanitize-coverage=[func|bb|edge]"
>> +<< "-fsanitize-coverage=[func|bb|edge],[trace-pc-guard|trace-pc
>> ]";
>> +  }
>> +
>>// trace-pc w/o func/bb/edge implies edge.
>>if ((CoverageFeatures & (CoverageTracePC | CoverageTracePCGuard)) &&
>> -  !(CoverageFeatures & CoverageTypes))
>> +  !(CoverageFeatures & InsertionPointTypes))
>>  CoverageFeatures |= CoverageEdge;
>>
>>if (AllAddedKinds & Address) {
>>
>> Modified: cfe/trunk/test/Driver/fsanitize-coverage.c
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fs
>> anitize-coverage.c?rev=301994&r1=301993&r2=301994&view=diff
>> 
>> ==
>> --- cfe/trunk/test/Driver/fsanitize-coverage.c (original)
>> +++ cfe/trunk/test/Driver/fsanitize-coverage.c Tue May  2 20:27:28 2017
>> @@ -4,12 +4,13 @@
>>  // CHECK-SANITIZE-COVERAGE-0-NOT: fsanitize-coverage-type
>>  // CHECK-SANITIZE-COVERAGE-0: -fsanitize=address
>>
>> -// RUN: %clang -target x86_64-linux-gnu -fsanitize=address
>> -fsanitize-coverage=func %s -### 2>&1 | FileCheck %s
>> --check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
>> -// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory
>> -fsanitize-coverage=func %s -### 2>&1 | FileCheck %s
>> --check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
>> -// RUN: %clang -target x86_64-linux-gnu -fsanitize=leak
>> -fsanitize-coverage=func %s -### 2>&1 | FileCheck %s
>> --check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
>> -// RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined
>> -fsanitize-coverage=func %s -### 2>&1 | FileCheck %s
>> --check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
>> -// RUN: %clang -target x86_64-linux-gnu -fsanitize=bool
>> -fsanitize-coverage=func %s -### 2>&1 | FileCheck %s
>> --check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
>> -// RUN: %clang -target x86_64-linux-gnu -fsanitize=dataflow
>> -fsanitize-coverage=func %s -### 2>&1 | FileCheck %s
>> --check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
>> +// RUN: %clang -target x86_64-linux-gnu -fsanitize=address
>> -fsanitize-coverage=func,trace-pc %s -### 2>&1 | FileCheck %s
>> --check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
>> +// RUN: %clang -target x86_64-linux-gnu -fsa

r302320 - [sanitizer-coverage] implement -fsanitize-coverage=no-prune, ... instead of a hidden -mllvm flag. clang part.

2017-05-05 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Fri May  5 18:28:18 2017
New Revision: 302320

URL: http://llvm.org/viewvc/llvm-project?rev=302320&view=rev
Log:
[sanitizer-coverage] implement -fsanitize-coverage=no-prune,... instead of a 
hidden -mllvm flag. clang part.

Modified:
cfe/trunk/docs/SanitizerCoverage.rst
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=302320&r1=302319&r2=302320&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Fri May  5 18:28:18 2017
@@ -144,8 +144,9 @@ Use these flags together with ``trace-pc
 like this: ``-fsanitize-coverage=func,trace-pc-guard``.
 
 When ``edge`` or ``bb`` is used, some of the edges/blocks may still be left
-uninstrumented if such instrumentation is considered redundant.
-**TODO**: add a user-visible option to disable the optimization.
+uninstrumented (pruned) if such instrumentation is considered redundant.
+Use ``no-prune`` (e.g. ``-fsanitize-coverage=bb,no-prune,trace-pc-guard``)
+to disable pruning. This could be useful for better coverage visualization.
 
 
 Edge coverage

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=302320&r1=302319&r2=302320&view=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Fri May  5 18:28:18 2017
@@ -297,6 +297,9 @@ def fsanitize_coverage_trace_pc
 def fsanitize_coverage_trace_pc_guard
 : Flag<["-"], "fsanitize-coverage-trace-pc-guard">,
   HelpText<"Enable PC tracing with guard in sanitizer coverage">;
+def fsanitize_coverage_no_prune
+: Flag<["-"], "fsanitize-coverage-no-prune">,
+  HelpText<"Disable coverage pruning (i.e. instrument all blocks/edges)">;
 def fprofile_instrument_EQ : Joined<["-"], "fprofile-instrument=">,
 HelpText<"Enable PGO instrumentation. The accepted value is clang, llvm, "
  "or none">;

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=302320&r1=302319&r2=302320&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Fri May  5 18:28:18 2017
@@ -160,6 +160,7 @@ CODEGENOPT(SanitizeCoverageTracePC, 1, 0
   ///< in sanitizer coverage.
 CODEGENOPT(SanitizeCoverageTracePCGuard, 1, 0) ///< Enable PC tracing with 
guard
///< in sanitizer coverage.
+CODEGENOPT(SanitizeCoverageNoPrune, 1, 0) ///< Disable coverage pruning.
 CODEGENOPT(SanitizeStats , 1, 0) ///< Collect statistics for sanitizers.
 CODEGENOPT(SimplifyLibCalls  , 1, 1) ///< Set when -fbuiltin is enabled.
 CODEGENOPT(SoftFloat , 1, 0) ///< -soft-float.

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=302320&r1=302319&r2=302320&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Fri May  5 18:28:18 2017
@@ -185,6 +185,7 @@ static void addSanitizerCoveragePass(con
   Opts.Use8bitCounters = CGOpts.SanitizeCoverage8bitCounters;
   Opts.TracePC = CGOpts.SanitizeCoverageTracePC;
   Opts.TracePCGuard = CGOpts.SanitizeCoverageTracePCGuard;
+  Opts.NoPrune = CGOpts.SanitizeCoverageNoPrune;
   PM.add(createSanitizerCoverageModulePass(Opts));
 }
 

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=302320&r1=302319&r2=302320&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Fri May  5 18:28:18 2017
@@ -55,6 +55,7 @@ enum CoverageFeature {
   Coverage8bitCounters = 1 << 8,
   CoverageTracePC = 1 << 9,
   CoverageTracePCGuard = 1 << 10,
+  CoverageNoPrune = 1 << 11,
 };
 
 /// Parse a -fsanitize= or -fno-sanitize= argument's values, diagnosing any
@@ -629,7 +630,8 @@ void SanitizerArgs::addArgs(const ToolCh
 std::make_pair(CoverageTraceGep, "-fsanitize-coverage-trace-gep"),
 std::make_pair(Coverage8bitCounters, "-fsanitize-cover

Re: r284272 - Implement no_sanitize_address for global vars

2016-10-17 Thread Kostya Serebryany via cfe-commits
Did you code-review this?
(sorry if I missed it)

On Fri, Oct 14, 2016 at 12:55 PM, Douglas Katzman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: dougk
> Date: Fri Oct 14 14:55:09 2016
> New Revision: 284272
>
> URL: http://llvm.org/viewvc/llvm-project?rev=284272&view=rev
> Log:
> Implement no_sanitize_address for global vars
>
> Modified:
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/include/clang/Sema/AttributeList.h
> cfe/trunk/lib/CodeGen/SanitizerMetadata.cpp
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/test/CodeGen/asan-globals.cpp
> cfe/trunk/test/SemaCXX/attr-no-sanitize-address.cpp
> cfe/trunk/test/SemaCXX/attr-no-sanitize.cpp
>
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Basic/Attr.td?rev=284272&r1=284271&r2=284272&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Fri Oct 14 14:55:09 2016
> @@ -1705,7 +1705,8 @@ def X86ForceAlignArgPointer : Inheritabl
>  def NoSanitize : InheritableAttr {
>let Spellings = [GNU<"no_sanitize">, CXX11<"clang", "no_sanitize">];
>let Args = [VariadicStringArgument<"Sanitizers">];
> -  let Subjects = SubjectList<[Function, ObjCMethod], ErrorDiag>;
> +  let Subjects = SubjectList<[Function, ObjCMethod, GlobalVar], ErrorDiag,
> +"ExpectedFunctionMethodOrGlobalVar">;
>let Documentation = [NoSanitizeDocs];
>let AdditionalMembers = [{
>  SanitizerMask getMask() const {
> @@ -1727,7 +1728,8 @@ def NoSanitizeSpecific : InheritableAttr
> GCC<"no_sanitize_address">,
> GCC<"no_sanitize_thread">,
> GNU<"no_sanitize_memory">];
> -  let Subjects = SubjectList<[Function], ErrorDiag>;
> +  let Subjects = SubjectList<[Function, GlobalVar], ErrorDiag,
> +"ExpectedFunctionGlobalVarMethodOrProperty">;
>let Documentation = [NoSanitizeAddressDocs, NoSanitizeThreadDocs,
> NoSanitizeMemoryDocs];
>let ASTNode = 0;
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/
> DiagnosticSemaKinds.td?rev=284272&r1=284271&r2=284272&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Oct 14
> 14:55:09 2016
> @@ -2577,6 +2577,7 @@ def warn_attribute_wrong_decl_type : War
>"|functions, methods and blocks"
>"|functions, methods, and classes"
>"|functions, methods, and parameters"
> +  "|functions, methods, and global variables"
>"|classes"
>"|enums"
>"|variables"
>
> Modified: cfe/trunk/include/clang/Sema/AttributeList.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Sema/AttributeList.h?rev=284272&r1=284271&r2=284272&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Sema/AttributeList.h (original)
> +++ cfe/trunk/include/clang/Sema/AttributeList.h Fri Oct 14 14:55:09 2016
> @@ -891,6 +891,7 @@ enum AttributeDeclKind {
>ExpectedFunctionMethodOrBlock,
>ExpectedFunctionMethodOrClass,
>ExpectedFunctionMethodOrParameter,
> +  ExpectedFunctionMethodOrGlobalVar,
>ExpectedClass,
>ExpectedEnum,
>ExpectedVariable,
>
> Modified: cfe/trunk/lib/CodeGen/SanitizerMetadata.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> SanitizerMetadata.cpp?rev=284272&r1=284271&r2=284272&view=diff
> 
> ==
> --- cfe/trunk/lib/CodeGen/SanitizerMetadata.cpp (original)
> +++ cfe/trunk/lib/CodeGen/SanitizerMetadata.cpp Fri Oct 14 14:55:09 2016
> @@ -63,7 +63,13 @@ void SanitizerMetadata::reportGlobalToAS
>std::string QualName;
>llvm::raw_string_ostream OS(QualName);
>D.printQualifiedName(OS);
> -  reportGlobalToASan(GV, D.getLocation(), OS.str(), D.getType(),
> IsDynInit);
> +
> +  bool IsBlacklisted = false;
> +  for (auto Attr : D.specific_attrs())
> +if (Attr->getMask() & SanitizerKind::Address)
> +  IsBlacklisted = true;
> +  reportGlobalToASan(GV, D.getLocation(), OS.str(), D.getType(),
> IsDynInit,
> + IsBlacklisted);
>  }
>
>  void SanitizerMetadata::disableSanitizerForGlobal(llvm::GlobalVariable
> *GV) {
>
> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/
> SemaDeclAttr.cpp?rev=284272&r1=284271&r2=284272&view=diff
> 
> ==
> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDeclAttr.

Re: r284272 - Implement no_sanitize_address for global vars

2016-10-25 Thread Kostya Serebryany via cfe-commits
ping

On Mon, Oct 17, 2016 at 5:57 PM, Kostya Serebryany  wrote:

> Did you code-review this?
> (sorry if I missed it)
>
> On Fri, Oct 14, 2016 at 12:55 PM, Douglas Katzman via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: dougk
>> Date: Fri Oct 14 14:55:09 2016
>> New Revision: 284272
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=284272&view=rev
>> Log:
>> Implement no_sanitize_address for global vars
>>
>> Modified:
>> cfe/trunk/include/clang/Basic/Attr.td
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> cfe/trunk/include/clang/Sema/AttributeList.h
>> cfe/trunk/lib/CodeGen/SanitizerMetadata.cpp
>> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>> cfe/trunk/test/CodeGen/asan-globals.cpp
>> cfe/trunk/test/SemaCXX/attr-no-sanitize-address.cpp
>> cfe/trunk/test/SemaCXX/attr-no-sanitize.cpp
>>
>> Modified: cfe/trunk/include/clang/Basic/Attr.td
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Basic/Attr.td?rev=284272&r1=284271&r2=284272&view=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Basic/Attr.td (original)
>> +++ cfe/trunk/include/clang/Basic/Attr.td Fri Oct 14 14:55:09 2016
>> @@ -1705,7 +1705,8 @@ def X86ForceAlignArgPointer : Inheritabl
>>  def NoSanitize : InheritableAttr {
>>let Spellings = [GNU<"no_sanitize">, CXX11<"clang", "no_sanitize">];
>>let Args = [VariadicStringArgument<"Sanitizers">];
>> -  let Subjects = SubjectList<[Function, ObjCMethod], ErrorDiag>;
>> +  let Subjects = SubjectList<[Function, ObjCMethod, GlobalVar],
>> ErrorDiag,
>> +"ExpectedFunctionMethodOrGlobalVar">;
>>let Documentation = [NoSanitizeDocs];
>>let AdditionalMembers = [{
>>  SanitizerMask getMask() const {
>> @@ -1727,7 +1728,8 @@ def NoSanitizeSpecific : InheritableAttr
>> GCC<"no_sanitize_address">,
>> GCC<"no_sanitize_thread">,
>> GNU<"no_sanitize_memory">];
>> -  let Subjects = SubjectList<[Function], ErrorDiag>;
>> +  let Subjects = SubjectList<[Function, GlobalVar], ErrorDiag,
>> +"ExpectedFunctionGlobalVarMethodOrProperty">;
>>let Documentation = [NoSanitizeAddressDocs, NoSanitizeThreadDocs,
>> NoSanitizeMemoryDocs];
>>let ASTNode = 0;
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Basic/DiagnosticSemaKinds.td?rev=284272&r1=284271&r2=284272&view=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Oct 14
>> 14:55:09 2016
>> @@ -2577,6 +2577,7 @@ def warn_attribute_wrong_decl_type : War
>>"|functions, methods and blocks"
>>"|functions, methods, and classes"
>>"|functions, methods, and parameters"
>> +  "|functions, methods, and global variables"
>>"|classes"
>>"|enums"
>>"|variables"
>>
>> Modified: cfe/trunk/include/clang/Sema/AttributeList.h
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Sema/AttributeList.h?rev=284272&r1=284271&r2=284272&view=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Sema/AttributeList.h (original)
>> +++ cfe/trunk/include/clang/Sema/AttributeList.h Fri Oct 14 14:55:09 2016
>> @@ -891,6 +891,7 @@ enum AttributeDeclKind {
>>ExpectedFunctionMethodOrBlock,
>>ExpectedFunctionMethodOrClass,
>>ExpectedFunctionMethodOrParameter,
>> +  ExpectedFunctionMethodOrGlobalVar,
>>ExpectedClass,
>>ExpectedEnum,
>>ExpectedVariable,
>>
>> Modified: cfe/trunk/lib/CodeGen/SanitizerMetadata.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/Sa
>> nitizerMetadata.cpp?rev=284272&r1=284271&r2=284272&view=diff
>> 
>> ==
>> --- cfe/trunk/lib/CodeGen/SanitizerMetadata.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/SanitizerMetadata.cpp Fri Oct 14 14:55:09 2016
>> @@ -63,7 +63,13 @@ void SanitizerMetadata::reportGlobalToAS
>>std::string QualName;
>>llvm::raw_string_ostream OS(QualName);
>>D.printQualifiedName(OS);
>> -  reportGlobalToASan(GV, D.getLocation(), OS.str(), D.getType(),
>> IsDynInit);
>> +
>> +  bool IsBlacklisted = false;
>> +  for (auto Attr : D.specific_attrs())
>> +if (Attr->getMask() & SanitizerKind::Address)
>> +  IsBlacklisted = true;
>> +  reportGlobalToASan(GV, D.getLocation(), OS.str(), D.getType(),
>> IsDynInit,
>> + IsBlacklisted);
>>  }
>>
>>  void SanitizerMetadata::disableSanitizerForGlobal(llvm::GlobalVariable
>> *GV) {
>>
>> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaD
>> eclAttr.cpp?rev=284272&r1=284271&r2=28427

Re: r286096 - Deduplicate replacements by FileEntry instead of file names.

2016-11-07 Thread Kostya Serebryany via cfe-commits
Hi Eric,

the asan bootstrap bot shows a leak in this newly added tests. Please fix
or revert ASAP.
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/136/steps/check-clang%20asan/logs/stdio

Direct leak of 720 byte(s) in 1 object(s) allocated from:
#0 0x6ace50 in operator new(unsigned long)
/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:82
#1 0xc83f64 in
clang::tooling::DeduplicateByFileTest_NonExistingFilePath_Test::TestBody()
/mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/unittests/Tooling/Re


On Sun, Nov 6, 2016 at 10:08 PM, Eric Liu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: ioeric
> Date: Mon Nov  7 00:08:23 2016
> New Revision: 286096
>
> URL: http://llvm.org/viewvc/llvm-project?rev=286096&view=rev
> Log:
> Deduplicate replacements by FileEntry instead of file names.
>
> Summary:
> The current version does not deduplicate equivalent file paths correctly.
> For example, a relative path and an absolute path are considered
> inequivalent.
> Comparing FileEnry addresses these issues.
>
> Reviewers: djasper
>
> Subscribers: alexshap, klimek, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D26288
>
> Modified:
> cfe/trunk/include/clang/Tooling/Core/Replacement.h
> cfe/trunk/lib/Tooling/Core/Replacement.cpp
> cfe/trunk/lib/Tooling/Refactoring.cpp
> cfe/trunk/unittests/Tooling/RefactoringTest.cpp
>
> Modified: cfe/trunk/include/clang/Tooling/Core/Replacement.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Tooling/Core/Replacement.h?rev=286096&r1=286095&r2=286096&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Tooling/Core/Replacement.h (original)
> +++ cfe/trunk/include/clang/Tooling/Core/Replacement.h Mon Nov  7
> 00:08:23 2016
> @@ -19,6 +19,7 @@
>  #ifndef LLVM_CLANG_TOOLING_CORE_REPLACEMENT_H
>  #define LLVM_CLANG_TOOLING_CORE_REPLACEMENT_H
>
> +#include "clang/Basic/FileManager.h"
>  #include "clang/Basic/LangOptions.h"
>  #include "clang/Basic/SourceLocation.h"
>  #include "llvm/ADT/StringRef.h"
> @@ -293,9 +294,10 @@ calculateRangesAfterReplacements(const R
>   const std::vector &Ranges);
>
>  /// \brief If there are multiple  pairs with the same
> file
> -/// path after removing dots, we only keep one pair (with path after dots
> being
> -/// removed) and discard the rest.
> +/// entry, we only keep one pair and discard the rest.
> +/// If a file does not exist, its corresponding replacements will be
> ignored.
>  std::map groupReplacementsByFile(
> +FileManager &FileMgr,
>  const std::map &FileToReplaces);
>
>  template 
>
> Modified: cfe/trunk/lib/Tooling/Core/Replacement.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/
> Core/Replacement.cpp?rev=286096&r1=286095&r2=286096&view=diff
> 
> ==
> --- cfe/trunk/lib/Tooling/Core/Replacement.cpp (original)
> +++ cfe/trunk/lib/Tooling/Core/Replacement.cpp Mon Nov  7 00:08:23 2016
> @@ -20,6 +20,7 @@
>  #include "clang/Basic/SourceManager.h"
>  #include "clang/Lex/Lexer.h"
>  #include "clang/Rewrite/Core/Rewriter.h"
> +#include "llvm/ADT/SmallPtrSet.h"
>  #include "llvm/Support/FileSystem.h"
>  #include "llvm/Support/Path.h"
>  #include "llvm/Support/raw_os_ostream.h"
> @@ -566,12 +567,16 @@ llvm::Expected applyAllRepl
>  }
>
>  std::map groupReplacementsByFile(
> +FileManager &FileMgr,
>  const std::map &FileToReplaces) {
>std::map Result;
> +  llvm::SmallPtrSet ProcessedFileEntries;
>for (const auto &Entry : FileToReplaces) {
> -llvm::SmallString<256> CleanPath(Entry.first);
> -llvm::sys::path::remove_dots(CleanPath, /*remove_dot_dot=*/true);
> -Result[CleanPath.str()] = std::move(Entry.second);
> +const FileEntry *FE = FileMgr.getFile(Entry.first);
> +if (!FE)
> +  llvm::errs() << "File path " << Entry.first << " is invalid.\n";
> +else if (ProcessedFileEntries.insert(FE).second)
> +  Result[Entry.first] = std::move(Entry.second);
>}
>return Result;
>  }
>
> Modified: cfe/trunk/lib/Tooling/Refactoring.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/
> Refactoring.cpp?rev=286096&r1=286095&r2=286096&view=diff
> 
> ==
> --- cfe/trunk/lib/Tooling/Refactoring.cpp (original)
> +++ cfe/trunk/lib/Tooling/Refactoring.cpp Mon Nov  7 00:08:23 2016
> @@ -57,7 +57,8 @@ int RefactoringTool::runAndSave(Frontend
>
>  bool RefactoringTool::applyAllReplacements(Rewriter &Rewrite) {
>bool Result = true;
> -  for (const auto &Entry : groupReplacementsByFile(FileToReplaces))
> +  for (const auto &Entry : groupReplacementsByFile(
> +   Rewrite.getSourceMgr().getFileManager(), FileToReplaces

Re: r286096 - Deduplicate replacements by FileEntry instead of file names.

2016-11-07 Thread Kostya Serebryany via cfe-commits
Thanks!

On Mon, Nov 7, 2016 at 10:53 AM, Eric Liu  wrote:

> r286132 should fix this.
>
> On Mon, Nov 7, 2016 at 10:40 AM Eric Liu  wrote:
>
> Thanks Kostya! I'll look into this now.
>
> On Mon, Nov 7, 2016 at 10:39 AM Kostya Serebryany  wrote:
>
> Hi Eric,
>
> the asan bootstrap bot shows a leak in this newly added tests. Please fix
> or revert ASAP.
> http://lab.llvm.org:8011/builders/sanitizer-x86_64-
> linux-bootstrap/builds/136/steps/check-clang%20asan/logs/stdio
>
> Direct leak of 720 byte(s) in 1 object(s) allocated from:
> #0 0x6ace50 in operator new(unsigned long) 
> /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:82
> #1 0xc83f64 in 
> clang::tooling::DeduplicateByFileTest_NonExistingFilePath_Test::TestBody() 
> /mnt/b/sanitizer-buildbot2/sanitizer-x86_64-linux-bootstrap/build/llvm/tools/clang/unittests/Tooling/Re
>
>
> On Sun, Nov 6, 2016 at 10:08 PM, Eric Liu via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> Author: ioeric
> Date: Mon Nov  7 00:08:23 2016
> New Revision: 286096
>
> URL: http://llvm.org/viewvc/llvm-project?rev=286096&view=rev
> Log:
> Deduplicate replacements by FileEntry instead of file names.
>
> Summary:
> The current version does not deduplicate equivalent file paths correctly.
> For example, a relative path and an absolute path are considered
> inequivalent.
> Comparing FileEnry addresses these issues.
>
> Reviewers: djasper
>
> Subscribers: alexshap, klimek, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D26288
>
> Modified:
> cfe/trunk/include/clang/Tooling/Core/Replacement.h
> cfe/trunk/lib/Tooling/Core/Replacement.cpp
> cfe/trunk/lib/Tooling/Refactoring.cpp
> cfe/trunk/unittests/Tooling/RefactoringTest.cpp
>
> Modified: cfe/trunk/include/clang/Tooling/Core/Replacement.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Tooling/Core/Replacement.h?rev=286096&r1=286095&r2=286096&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Tooling/Core/Replacement.h (original)
> +++ cfe/trunk/include/clang/Tooling/Core/Replacement.h Mon Nov  7
> 00:08:23 2016
> @@ -19,6 +19,7 @@
>  #ifndef LLVM_CLANG_TOOLING_CORE_REPLACEMENT_H
>  #define LLVM_CLANG_TOOLING_CORE_REPLACEMENT_H
>
> +#include "clang/Basic/FileManager.h"
>  #include "clang/Basic/LangOptions.h"
>  #include "clang/Basic/SourceLocation.h"
>  #include "llvm/ADT/StringRef.h"
> @@ -293,9 +294,10 @@ calculateRangesAfterReplacements(const R
>   const std::vector &Ranges);
>
>  /// \brief If there are multiple  pairs with the same
> file
> -/// path after removing dots, we only keep one pair (with path after dots
> being
> -/// removed) and discard the rest.
> +/// entry, we only keep one pair and discard the rest.
> +/// If a file does not exist, its corresponding replacements will be
> ignored.
>  std::map groupReplacementsByFile(
> +FileManager &FileMgr,
>  const std::map &FileToReplaces);
>
>  template 
>
> Modified: cfe/trunk/lib/Tooling/Core/Replacement.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/
> Core/Replacement.cpp?rev=286096&r1=286095&r2=286096&view=diff
> 
> ==
> --- cfe/trunk/lib/Tooling/Core/Replacement.cpp (original)
> +++ cfe/trunk/lib/Tooling/Core/Replacement.cpp Mon Nov  7 00:08:23 2016
> @@ -20,6 +20,7 @@
>  #include "clang/Basic/SourceManager.h"
>  #include "clang/Lex/Lexer.h"
>  #include "clang/Rewrite/Core/Rewriter.h"
> +#include "llvm/ADT/SmallPtrSet.h"
>  #include "llvm/Support/FileSystem.h"
>  #include "llvm/Support/Path.h"
>  #include "llvm/Support/raw_os_ostream.h"
> @@ -566,12 +567,16 @@ llvm::Expected applyAllRepl
>  }
>
>  std::map groupReplacementsByFile(
> +FileManager &FileMgr,
>  const std::map &FileToReplaces) {
>std::map Result;
> +  llvm::SmallPtrSet ProcessedFileEntries;
>for (const auto &Entry : FileToReplaces) {
> -llvm::SmallString<256> CleanPath(Entry.first);
> -llvm::sys::path::remove_dots(CleanPath, /*remove_dot_dot=*/true);
> -Result[CleanPath.str()] = std::move(Entry.second);
> +const FileEntry *FE = FileMgr.getFile(Entry.first);
> +if (!FE)
> +  llvm::errs() << "File path " << Entry.first << " is invalid.\n";
> +else if (ProcessedFileEntries.insert(FE).second)
> +  Result[Entry.first] = std::move(Entry.second);
>}
>return Result;
>  }
>
> Modified: cfe/trunk/lib/Tooling/Refactoring.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/
> Refactoring.cpp?rev=286096&r1=286095&r2=286096&view=diff
> 
> ==
> --- cfe/trunk/lib/Tooling/Refactoring.cpp (original)
> +++ cfe/trunk/lib/Tooling/Refactoring.cpp Mon Nov  7 00:08:23 2016
> @@ -57,7 +57,8 @@ int RefactoringTool::runAndSave(Frontend
>
>  b

Re: r284272 - Implement no_sanitize_address for global vars

2016-11-08 Thread Kostya Serebryany via cfe-commits
On Tue, Nov 8, 2016 at 11:27 AM, Douglas Katzman  wrote:

> oh, sorry for missing this email.
> I'll say "no" - I was hoping you'd audit it!
>

We do indeed have this practice for post-commit audit, but only for the
authors or active maintainers of the piece of code in question.
I afraid I do not fully understand the consequences of this patch -- they
may be non-trivial.
Please initiate a code review (even though the code is already committed).

--kcc


>
> jyknight looked at it and gave me the suggestion to fail the attribute
> parsing if, in the non-deprecated syntax, _any_ of the no_sanitize
> modifiers are inapplicable to global vars.
>
> On Tue, Oct 25, 2016 at 7:19 PM, Kostya Serebryany  wrote:
>
>> ping
>>
>> On Mon, Oct 17, 2016 at 5:57 PM, Kostya Serebryany 
>> wrote:
>>
>>> Did you code-review this?
>>> (sorry if I missed it)
>>>
>>> On Fri, Oct 14, 2016 at 12:55 PM, Douglas Katzman via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: dougk
 Date: Fri Oct 14 14:55:09 2016
 New Revision: 284272

 URL: http://llvm.org/viewvc/llvm-project?rev=284272&view=rev
 Log:
 Implement no_sanitize_address for global vars

 Modified:
 cfe/trunk/include/clang/Basic/Attr.td
 cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
 cfe/trunk/include/clang/Sema/AttributeList.h
 cfe/trunk/lib/CodeGen/SanitizerMetadata.cpp
 cfe/trunk/lib/Sema/SemaDeclAttr.cpp
 cfe/trunk/test/CodeGen/asan-globals.cpp
 cfe/trunk/test/SemaCXX/attr-no-sanitize-address.cpp
 cfe/trunk/test/SemaCXX/attr-no-sanitize.cpp

 Modified: cfe/trunk/include/clang/Basic/Attr.td
 URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
 Basic/Attr.td?rev=284272&r1=284271&r2=284272&view=diff
 
 ==
 --- cfe/trunk/include/clang/Basic/Attr.td (original)
 +++ cfe/trunk/include/clang/Basic/Attr.td Fri Oct 14 14:55:09 2016
 @@ -1705,7 +1705,8 @@ def X86ForceAlignArgPointer : Inheritabl
  def NoSanitize : InheritableAttr {
let Spellings = [GNU<"no_sanitize">, CXX11<"clang", "no_sanitize">];
let Args = [VariadicStringArgument<"Sanitizers">];
 -  let Subjects = SubjectList<[Function, ObjCMethod], ErrorDiag>;
 +  let Subjects = SubjectList<[Function, ObjCMethod, GlobalVar],
 ErrorDiag,
 +"ExpectedFunctionMethodOrGlobalVar">;
let Documentation = [NoSanitizeDocs];
let AdditionalMembers = [{
  SanitizerMask getMask() const {
 @@ -1727,7 +1728,8 @@ def NoSanitizeSpecific : InheritableAttr
 GCC<"no_sanitize_address">,
 GCC<"no_sanitize_thread">,
 GNU<"no_sanitize_memory">];
 -  let Subjects = SubjectList<[Function], ErrorDiag>;
 +  let Subjects = SubjectList<[Function, GlobalVar], ErrorDiag,
 +"ExpectedFunctionGlobalVarMethodOrProperty">;
let Documentation = [NoSanitizeAddressDocs, NoSanitizeThreadDocs,
 NoSanitizeMemoryDocs];
let ASTNode = 0;

 Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
 URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
 Basic/DiagnosticSemaKinds.td?rev=284272&r1=284271&r2=284272&view=diff
 
 ==
 --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
 +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Oct 14
 14:55:09 2016
 @@ -2577,6 +2577,7 @@ def warn_attribute_wrong_decl_type : War
"|functions, methods and blocks"
"|functions, methods, and classes"
"|functions, methods, and parameters"
 +  "|functions, methods, and global variables"
"|classes"
"|enums"
"|variables"

 Modified: cfe/trunk/include/clang/Sema/AttributeList.h
 URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
 Sema/AttributeList.h?rev=284272&r1=284271&r2=284272&view=diff
 
 ==
 --- cfe/trunk/include/clang/Sema/AttributeList.h (original)
 +++ cfe/trunk/include/clang/Sema/AttributeList.h Fri Oct 14 14:55:09
 2016
 @@ -891,6 +891,7 @@ enum AttributeDeclKind {
ExpectedFunctionMethodOrBlock,
ExpectedFunctionMethodOrClass,
ExpectedFunctionMethodOrParameter,
 +  ExpectedFunctionMethodOrGlobalVar,
ExpectedClass,
ExpectedEnum,
ExpectedVariable,

 Modified: cfe/trunk/lib/CodeGen/SanitizerMetadata.cpp
 URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/Sa
 nitizerMetadata.cpp?rev=284272&r1=284271&r2=284272&view=diff
 
 ==
 --- cfe/trunk/lib/CodeGe

[PATCH] D26454: Implement no_sanitize_address for global vars

2016-11-11 Thread Kostya Serebryany via cfe-commits
kcc added a comment.

Does this change deserve a documentation update?


https://reviews.llvm.org/D26454



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


Re: [PATCH] D11857: CFI: Introduce -fsanitize=cfi-icall flag.

2015-09-09 Thread Kostya Serebryany 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: test/CodeGen/cfi-icall.c:1
@@ +1,2 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -fsanitize=cfi-icall 
-fsanitize-trap=cfi-icall -emit-llvm -o - %s | FileCheck --check-prefix=ITANIUM 
%s
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -fsanitize=cfi-icall 
-fsanitize-trap=cfi-icall -emit-llvm -o - %s | FileCheck --check-prefix=MS %s

Add a comment explaining what we are testing here.
same below. 


http://reviews.llvm.org/D11857



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


r249215 - [libFuzzer] make LLVMFuzzerTestOneInput (the fuzzer target function) return int instead of void. (following llvm r249214)

2015-10-02 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Fri Oct  2 18:34:37 2015
New Revision: 249215

URL: http://llvm.org/viewvc/llvm-project?rev=249215&view=rev
Log:
[libFuzzer] make LLVMFuzzerTestOneInput (the fuzzer target function) return int 
instead of void. (following llvm r249214)

Modified:
cfe/trunk/tools/clang-format/fuzzer/ClangFormatFuzzer.cpp
cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp

Modified: cfe/trunk/tools/clang-format/fuzzer/ClangFormatFuzzer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format/fuzzer/ClangFormatFuzzer.cpp?rev=249215&r1=249214&r2=249215&view=diff
==
--- cfe/trunk/tools/clang-format/fuzzer/ClangFormatFuzzer.cpp (original)
+++ cfe/trunk/tools/clang-format/fuzzer/ClangFormatFuzzer.cpp Fri Oct  2 
18:34:37 2015
@@ -15,11 +15,12 @@
 
 #include "clang/Format/Format.h"
 
-extern "C" void LLVMFuzzerTestOneInput(uint8_t *data, size_t size) {
+extern "C" int LLVMFuzzerTestOneInput(uint8_t *data, size_t size) {
   // FIXME: fuzz more things: different styles, different style features.
   std::string s((const char *)data, size);
   auto Style = getGoogleStyle(clang::format::FormatStyle::LK_Cpp);
   Style.ColumnLimit = 60;
   applyAllReplacements(s, clang::format::reformat(
   Style, s, {clang::tooling::Range(0, s.size())}));
+  return 0;
 }

Modified: cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp?rev=249215&r1=249214&r2=249215&view=diff
==
--- cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp (original)
+++ cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp Fri Oct  2 18:34:37 2015
@@ -20,7 +20,7 @@
 
 using namespace clang;
 
-extern "C" void LLVMFuzzerTestOneInput(uint8_t *data, size_t size) {
+extern "C" int LLVMFuzzerTestOneInput(uint8_t *data, size_t size) {
   std::string s((const char *)data, size);
   llvm::opt::ArgStringList CC1Args;
   CC1Args.push_back("-cc1");
@@ -43,4 +43,5 @@ extern "C" void LLVMFuzzerTestOneInput(u
   std::make_shared();
   action->runInvocation(Invocation.release(), Files.get(), PCHContainerOps,
 &Diags);
+  return 0;
 }


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


Re: [PATCH] D11857: CFI: Introduce -fsanitize=cfi-icall flag.

2015-08-24 Thread Kostya Serebryany via cfe-commits
kcc added inline comments.


Comment at: docs/ControlFlowIntegrity.rst:149
@@ +148,3 @@
+shared library boundaries are handled as if the callee was not compiled with
+``-fsanitize=cfi-icall``.
+

mention that LTO is require explicitly?


http://reviews.llvm.org/D11857



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


Re: [libcxxabi] r278579 - Fix ASAN failures in the demangler

2016-08-12 Thread Kostya Serebryany via cfe-commits
Sweet!
Did you fix all of the known crashers?



On Fri, Aug 12, 2016 at 5:02 PM, Mehdi Amini via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: mehdi_amini
> Date: Fri Aug 12 19:02:33 2016
> New Revision: 278579
>
> URL: http://llvm.org/viewvc/llvm-project?rev=278579&view=rev
> Log:
> Fix ASAN failures in the demangler
>
> These were found fuzzing with ASAN.
>
> Modified:
> libcxxabi/trunk/src/cxa_demangle.cpp
> libcxxabi/trunk/test/test_demangle.pass.cpp
>
> Modified: libcxxabi/trunk/src/cxa_demangle.cpp
> URL: http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/
> cxa_demangle.cpp?rev=278579&r1=278578&r2=278579&view=diff
> 
> ==
> --- libcxxabi/trunk/src/cxa_demangle.cpp (original)
> +++ libcxxabi/trunk/src/cxa_demangle.cpp Fri Aug 12 19:02:33 2016
> @@ -624,6 +624,8 @@ parse_const_cast_expr(const char* first,
>  return first;
>  auto expr = db.names.back().move_full();
>  db.names.pop_back();
> +if (db.names.empty())
> +return first;
>  db.names.back() = "const_cast<" +
> db.names.back().move_full() + ">(" + expr + ")";
>  first = t1;
>  }
> @@ -650,6 +652,8 @@ parse_dynamic_cast_expr(const char* firs
>  return first;
>  auto expr = db.names.back().move_full();
>  db.names.pop_back();
> +if (db.names.empty())
> +return first;
>  db.names.back() = "dynamic_cast<" +
> db.names.back().move_full() + ">(" + expr + ")";
>  first = t1;
>  }
> @@ -676,6 +680,8 @@ parse_reinterpret_cast_expr(const char*
>  return first;
>  auto expr = db.names.back().move_full();
>  db.names.pop_back();
> +if (db.names.empty())
> +return first;
>  db.names.back() = "reinterpret_cast<" +
> db.names.back().move_full() + ">(" + expr + ")";
>  first = t1;
>  }
> @@ -1294,6 +1300,8 @@ parse_dot_expr(const char* first, const
>  return first;
>  auto name = db.names.back().move_full();
>  db.names.pop_back();
> +if (db.names.empty())
> +return first;
>  db.names.back().first += "." + name;
>  first = t1;
>  }
> @@ -2896,6 +2904,8 @@ base_name(String& s)
>  ++c;
>  }
>  }
> +if (pe - pf <= 1)
> +  return String();
>  const char* p0 = pe - 1;
>  for (; p0 != pf; --p0)
>  {
> @@ -3016,7 +3026,8 @@ parse_unnamed_type_name(const char* firs
>  const char* t1 = parse_type(t0, last, db);
>  if (t1 == t0)
>  {
> -db.names.pop_back();
> +if(!db.names.empty())
> +db.names.pop_back();
>  return first;
>  }
>  if (db.names.size() < 2)
> @@ -3041,17 +3052,21 @@ parse_unnamed_type_name(const char* firs
>  }
>  t0 = t1;
>  }
> +if(db.names.empty())
> +  return first;
>  db.names.back().first.append(")");
>  }
>  if (t0 == last || *t0 != 'E')
>  {
> +  if(!db.names.empty())
>  db.names.pop_back();
>  return first;
>  }
>  ++t0;
>  if (t0 == last)
>  {
> -db.names.pop_back();
> +if(!db.names.empty())
> +  db.names.pop_back();
>  return first;
>  }
>  if (std::isdigit(*t0))
> @@ -3064,7 +3079,8 @@ parse_unnamed_type_name(const char* firs
>  }
>  if (t0 == last || *t0 != '_')
>  {
> -db.names.pop_back();
> +if(!db.names.empty())
> +  db.names.pop_back();
>  return first;
>  }
>  first = t0 + 1;
> @@ -3251,7 +3267,7 @@ parse_binary_expression(const char* firs
>  nm += ')';
>  first = t2;
>  }
> -else
> +else if(!db.names.empty())
>  db.names.pop_back();
>  }
>  return first;
> @@ -3490,7 +3506,7 @@ parse_expression(const char* first, cons
>  db.names.back() = "(" + op1 + ")[" + op2 + "]";
>  first = t2;
>  }
> -else
> +else if (!db.names.empty())
>  db.names.pop_back();
>  }
>  }
> @@ -3686,11 +3702,13 @@ parse_expression(const char* first, cons
> 

Re: [libcxxabi] r278579 - Fix ASAN failures in the demangler

2016-08-12 Thread Kostya Serebryany via cfe-commits
On Fri, Aug 12, 2016 at 5:26 PM, Mehdi Amini  wrote:

> This fixes all the crashers on Darwin (clang+libc++), that I could
> reproduce with ASAN+libFuzzer.
> It does not mean that there is no leaks, or that you won’t find more
> crashes with libstdc++ for instance.
>

Yea... On linux I hit a leak right away:
Direct leak of 12 byte(s) in 1 object(s) allocated from:
#0 0x4c1afe in realloc
#1 0x4f1663 in __cxa_demangle cxa_demangle.cpp:5012:47
#2 0x5215f8 in LLVMFuzzerTestOneInput cxa_demangle_fuzzer.cpp:11:3

With lsan disabled the fuzzer is running for 3 minutes / 20 cores w/o new
crashes.
Great improvement!!!

--kcc


>
> —
> Mehdi
>
> On Aug 12, 2016, at 5:21 PM, Kostya Serebryany  wrote:
>
> Sweet!
> Did you fix all of the known crashers?
>
>
>
> On Fri, Aug 12, 2016 at 5:02 PM, Mehdi Amini via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: mehdi_amini
>> Date: Fri Aug 12 19:02:33 2016
>> New Revision: 278579
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=278579&view=rev
>> Log:
>> Fix ASAN failures in the demangler
>>
>> These were found fuzzing with ASAN.
>>
>> Modified:
>> libcxxabi/trunk/src/cxa_demangle.cpp
>> libcxxabi/trunk/test/test_demangle.pass.cpp
>>
>> Modified: libcxxabi/trunk/src/cxa_demangle.cpp
>> URL: http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/cxa_
>> demangle.cpp?rev=278579&r1=278578&r2=278579&view=diff
>> 
>> ==
>> --- libcxxabi/trunk/src/cxa_demangle.cpp (original)
>> +++ libcxxabi/trunk/src/cxa_demangle.cpp Fri Aug 12 19:02:33 2016
>> @@ -624,6 +624,8 @@ parse_const_cast_expr(const char* first,
>>  return first;
>>  auto expr = db.names.back().move_full();
>>  db.names.pop_back();
>> +if (db.names.empty())
>> +return first;
>>  db.names.back() = "const_cast<" +
>> db.names.back().move_full() + ">(" + expr + ")";
>>  first = t1;
>>  }
>> @@ -650,6 +652,8 @@ parse_dynamic_cast_expr(const char* firs
>>  return first;
>>  auto expr = db.names.back().move_full();
>>  db.names.pop_back();
>> +if (db.names.empty())
>> +return first;
>>  db.names.back() = "dynamic_cast<" +
>> db.names.back().move_full() + ">(" + expr + ")";
>>  first = t1;
>>  }
>> @@ -676,6 +680,8 @@ parse_reinterpret_cast_expr(const char*
>>  return first;
>>  auto expr = db.names.back().move_full();
>>  db.names.pop_back();
>> +if (db.names.empty())
>> +return first;
>>  db.names.back() = "reinterpret_cast<" +
>> db.names.back().move_full() + ">(" + expr + ")";
>>  first = t1;
>>  }
>> @@ -1294,6 +1300,8 @@ parse_dot_expr(const char* first, const
>>  return first;
>>  auto name = db.names.back().move_full();
>>  db.names.pop_back();
>> +if (db.names.empty())
>> +return first;
>>  db.names.back().first += "." + name;
>>  first = t1;
>>  }
>> @@ -2896,6 +2904,8 @@ base_name(String& s)
>>  ++c;
>>  }
>>  }
>> +if (pe - pf <= 1)
>> +  return String();
>>  const char* p0 = pe - 1;
>>  for (; p0 != pf; --p0)
>>  {
>> @@ -3016,7 +3026,8 @@ parse_unnamed_type_name(const char* firs
>>  const char* t1 = parse_type(t0, last, db);
>>  if (t1 == t0)
>>  {
>> -db.names.pop_back();
>> +if(!db.names.empty())
>> +db.names.pop_back();
>>  return first;
>>  }
>>  if (db.names.size() < 2)
>> @@ -3041,17 +3052,21 @@ parse_unnamed_type_name(const char* firs
>>  }
>>  t0 = t1;
>>  }
>> +if(db.names.empty())
>> +  return first;
>>  db.names.back().first.append(")");
>>  }
>>  if (t0 == last || *t0 != 'E')
>>  {
>> +  if(!db.names.empty())
>>  db.names.pop_back();
>>  return first;
>>  }
>>  ++t0;
>>  if (t0 == last)
>>  {
>> -db.names.pop_back();
>> +if(!db.names.empty())
>> +  db.names.pop_back();
>>  return first;
>>  }
>>  if (std::isdigit(*t0))
>> @@ -3064,7 +3079,8 @@ parse_unnamed_type_name(const char* firs
>>  }
>>  if (t0 == last || *t0 != '_')
>>  {
>> -db.names.pop_back();
>> +if(!db.names.empty())
>> 

r261159 - [sanitizer-coverage] implement -fsanitize-coverage=trace-pc. This is similar to trace-bb, but has a different API. We already use the equivalent flag in GCC for Linux kernel fuzzing. We may

2016-02-17 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Wed Feb 17 15:34:43 2016
New Revision: 261159

URL: http://llvm.org/viewvc/llvm-project?rev=261159&view=rev
Log:
[sanitizer-coverage] implement -fsanitize-coverage=trace-pc. This is similar to 
trace-bb, but has a different API. We already use the equivalent flag in GCC 
for Linux kernel fuzzing. We may be able to use this flag with AFL too

Modified:
cfe/trunk/docs/SanitizerCoverage.rst
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=261159&r1=261158&r2=261159&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Wed Feb 17 15:34:43 2016
@@ -291,6 +291,17 @@ With ``-fsanitize-coverage=trace-bb`` th
 ``__sanitizer_cov_trace_basic_block(s32 *id)`` before every function, basic 
block, or edge
 (depending on the value of ``-fsanitize-coverage=[func,bb,edge]``).
 
+Tracing PCs
+===
+*Experimental* feature similar to tracing basic blocks, but with a different 
API.
+With ``-fsanitize-coverage=[func,bb,edge],trace-pc`` the compiler will insert
+``__sanitizer_cov_trace_pc()`` on every function/block/edge.
+With and additional ``indirect-calls`` flag
+``__sanitizer_cov_trace_pc_indirect(void *callee)`` will be inserted on every 
indirect call.
+These callbacks are not implemented in the Sanitizer run-time and should be 
defined
+by the user.
+This mechanism is used for fuzzing the Linux kernel 
(https://github.com/google/syzkaller).
+
 Tracing data flow
 =
 

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=261159&r1=261158&r2=261159&view=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Wed Feb 17 15:34:43 2016
@@ -270,6 +270,9 @@ def fsanitize_coverage_trace_cmp
 def fsanitize_coverage_8bit_counters
 : Flag<["-"], "fsanitize-coverage-8bit-counters">,
   HelpText<"Enable frequency counters in sanitizer coverage">;
+def fsanitize_coverage_trace_pc
+: Flag<["-"], "fsanitize-coverage-trace-pc">,
+  HelpText<"Enable PC tracing in sanitizer coverage">;
 def fprofile_instrument_EQ : Joined<["-"], "fprofile-instrument=">,
 HelpText<"Enable PGO instrumentation. The accepted values is clang or "
  "none">;

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=261159&r1=261158&r2=261159&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Wed Feb 17 15:34:43 2016
@@ -134,6 +134,8 @@ CODEGENOPT(SanitizeCoverageTraceCmp, 1,
///< in sanitizer coverage.
 CODEGENOPT(SanitizeCoverage8bitCounters, 1, 0) ///< Use 8-bit frequency 
counters
///< in sanitizer coverage.
+CODEGENOPT(SanitizeCoverageTracePC, 1, 0) ///< Enable PC tracing
+  ///< in sanitizer coverage.
 CODEGENOPT(SanitizeStats , 1, 0) ///< Collect statistics for sanitizers.
 CODEGENOPT(SimplifyLibCalls  , 1, 1) ///< Set when -fbuiltin is enabled.
 CODEGENOPT(SoftFloat , 1, 0) ///< -soft-float.

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=261159&r1=261158&r2=261159&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Wed Feb 17 15:34:43 2016
@@ -189,6 +189,7 @@ static void addSanitizerCoveragePass(con
   Opts.TraceBB = CGOpts.SanitizeCoverageTraceBB;
   Opts.TraceCmp = CGOpts.SanitizeCoverageTraceCmp;
   Opts.Use8bitCounters = CGOpts.SanitizeCoverage8bitCounters;
+  Opts.TracePC = CGOpts.SanitizeCoverageTracePC;
   PM.add(createSanitizerCoverageModulePass(Opts));
 }
 

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=261159&r1=261158&r2=261159&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Wed Feb 17 15:34:43 2016
@@ -49,6 +49,7 @@ enu

r261178 - [sanitizer-coverage] add a deprecation warning for -fsanitize-coverage=[1234]

2016-02-17 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Wed Feb 17 17:57:17 2016
New Revision: 261178

URL: http://llvm.org/viewvc/llvm-project?rev=261178&view=rev
Log:
[sanitizer-coverage] add a deprecation warning for -fsanitize-coverage=[1234]

Modified:
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=261178&r1=261177&r2=261178&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Wed Feb 17 17:57:17 2016
@@ -446,6 +446,8 @@ SanitizerArgs::SanitizerArgs(const ToolC
 !StringRef(Arg->getValue(0))
  .getAsInteger(0, LegacySanitizeCoverage) &&
 LegacySanitizeCoverage >= 0 && LegacySanitizeCoverage <= 4) {
+  D.Diag(diag::warn_drv_deprecated_arg)
+  << Arg->getAsString(Args) << 
"-fsanitize-coverage=[func,bb,edge]";
   // TODO: Add deprecation notice for this form.
   switch (LegacySanitizeCoverage) {
   case 0:

Modified: cfe/trunk/test/Driver/fsanitize-coverage.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize-coverage.c?rev=261178&r1=261177&r2=261178&view=diff
==
--- cfe/trunk/test/Driver/fsanitize-coverage.c (original)
+++ cfe/trunk/test/Driver/fsanitize-coverage.c Wed Feb 17 17:57:17 2016
@@ -3,32 +3,35 @@
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-SANITIZE-COVERAGE-0
 // CHECK-SANITIZE-COVERAGE-0-NOT: fsanitize-coverage-type
 
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=1 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-1
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory 
-fsanitize-coverage=1 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-1
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=leak -fsanitize-coverage=1 
%s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANITIZE-COVERAGE-1
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined 
-fsanitize-coverage=1 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-1
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=bool -fsanitize-coverage=1 
%s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANITIZE-COVERAGE-1
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=dataflow 
-fsanitize-coverage=1 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-1
-// CHECK-SANITIZE-COVERAGE-1: fsanitize-coverage-type=1
-
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=2 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-2
-// CHECK-SANITIZE-COVERAGE-2: fsanitize-coverage-type=2
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=memory 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=leak 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=bool 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=dataflow 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
+// CHECK-SANITIZE-COVERAGE-FUNC: fsanitize-coverage-type=1
+
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=bb %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-BB
+// CHECK-SANITIZE-COVERAGE-BB: fsanitize-coverage-type=2
+
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=edge %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-EDGE
+// CHECK-SANITIZE-COVERAGE-EDGE: fsanitize-coverage-type=3
+
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=edge,indirect-calls %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC_INDIR
+// CHECK-SANITIZE-COVERAGE-FUNC_INDIR: fsanitize-coverage-type=3
+// CHECK-SANITIZE-COVERAGE-FUNC_INDIR: fsanitize-coverage-indirect-calls
 
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=3 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-3
-// CHECK-SANITIZE-COVERAGE-3: fsanitize-coverage-type=3
-
-// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 

r261182 - [sanitizer-coverage] allow -fsanitize-coverage=trace-pc w/o any other sanitizer and w/o ...=[func, bb, edge]. This makes this syntax a superset of the GCC's syntax

2016-02-17 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Wed Feb 17 18:49:23 2016
New Revision: 261182

URL: http://llvm.org/viewvc/llvm-project?rev=261182&view=rev
Log:
[sanitizer-coverage] allow -fsanitize-coverage=trace-pc w/o any other sanitizer 
and w/o ...=[func,bb,edge]. This makes this syntax a superset of the GCC's 
syntax

Modified:
cfe/trunk/docs/SanitizerCoverage.rst
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=261182&r1=261181&r2=261182&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Wed Feb 17 18:49:23 2016
@@ -294,13 +294,14 @@ With ``-fsanitize-coverage=trace-bb`` th
 Tracing PCs
 ===
 *Experimental* feature similar to tracing basic blocks, but with a different 
API.
-With ``-fsanitize-coverage=[func,bb,edge],trace-pc`` the compiler will insert
-``__sanitizer_cov_trace_pc()`` on every function/block/edge.
-With and additional ``indirect-calls`` flag
+With ``-fsanitize-coverage=trace-pc`` the compiler will insert
+``__sanitizer_cov_trace_pc()`` on every edge.
+With an additional ``...=trace-pc,indirect-calls`` flag
 ``__sanitizer_cov_trace_pc_indirect(void *callee)`` will be inserted on every 
indirect call.
 These callbacks are not implemented in the Sanitizer run-time and should be 
defined
-by the user.
-This mechanism is used for fuzzing the Linux kernel 
(https://github.com/google/syzkaller).
+by the user. So, these flags do not require the other sanitizer to be used.
+This mechanism is used for fuzzing the Linux kernel 
(https://github.com/google/syzkaller)
+and can be used with `AFL `_.
 
 Tracing data flow
 =

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=261182&r1=261181&r2=261182&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Wed Feb 17 18:49:23 2016
@@ -437,42 +437,45 @@ SanitizerArgs::SanitizerArgs(const ToolC
 
   // Parse -f(no-)?sanitize-coverage flags if coverage is supported by the
   // enabled sanitizers.
-  if (AllAddedKinds & SupportsCoverage) {
-for (const auto *Arg : Args) {
-  if (Arg->getOption().matches(options::OPT_fsanitize_coverage)) {
-Arg->claim();
-int LegacySanitizeCoverage;
-if (Arg->getNumValues() == 1 &&
-!StringRef(Arg->getValue(0))
- .getAsInteger(0, LegacySanitizeCoverage) &&
-LegacySanitizeCoverage >= 0 && LegacySanitizeCoverage <= 4) {
-  D.Diag(diag::warn_drv_deprecated_arg)
-  << Arg->getAsString(Args) << 
"-fsanitize-coverage=[func,bb,edge]";
-  // TODO: Add deprecation notice for this form.
-  switch (LegacySanitizeCoverage) {
-  case 0:
-CoverageFeatures = 0;
-break;
-  case 1:
-CoverageFeatures = CoverageFunc;
-break;
-  case 2:
-CoverageFeatures = CoverageBB;
-break;
-  case 3:
-CoverageFeatures = CoverageEdge;
-break;
-  case 4:
-CoverageFeatures = CoverageEdge | CoverageIndirCall;
-break;
-  }
-  continue;
+  for (const auto *Arg : Args) {
+if (Arg->getOption().matches(options::OPT_fsanitize_coverage)) {
+  int LegacySanitizeCoverage;
+  if (Arg->getNumValues() == 1 &&
+  !StringRef(Arg->getValue(0))
+   .getAsInteger(0, LegacySanitizeCoverage) &&
+  LegacySanitizeCoverage >= 0 && LegacySanitizeCoverage <= 4) {
+D.Diag(diag::warn_drv_deprecated_arg)
+<< Arg->getAsString(Args) << "-fsanitize-coverage=[func,bb,edge]";
+// TODO: Add deprecation notice for this form.
+switch (LegacySanitizeCoverage) {
+case 0:
+  CoverageFeatures = 0;
+  break;
+case 1:
+  CoverageFeatures = CoverageFunc;
+  break;
+case 2:
+  CoverageFeatures = CoverageBB;
+  break;
+case 3:
+  CoverageFeatures = CoverageEdge;
+  break;
+case 4:
+  CoverageFeatures = CoverageEdge | CoverageIndirCall;
+  break;
 }
-CoverageFeatures |= parseCoverageFeatures(D, Arg);
-  } else if (Arg->getOption().matches(options::OPT_fno_sanitize_coverage)) 
{
+continue;
+  }
+  CoverageFeatures |= parseCoverageFeatures(D, Arg);
+  // If there is trace-pc, allow it w/o any of the sanitizers.
+  // Otherwise, require that one of the supported sanitizers is present.
+  if ((CoverageFeatures & CoverageTracePC) ||
+  (AllAddedKi

Re: [PATCH] D17397: Make deprecation message for -fsanitize-coverage= with numeric argument friendlier.

2016-02-18 Thread Kostya Serebryany via cfe-commits
kcc accepted this revision.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM
Thanks! 
I don't see much value in doing this, but also don't mind.


http://reviews.llvm.org/D17397



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


Re: r267496 - [lanai] Update handling of structs in arguments to be passed in registers.

2016-04-26 Thread Kostya Serebryany via cfe-commits
On Tue, Apr 26, 2016 at 6:49 AM, Jacques Pienaar 
wrote:

> Thanks for fixing this. My apologies for breaking this and not noticing &
> fixing it earlier.
>

no problem.


> Is there any way to test the Windows build without a Windows machine at my
> disposal?
>

Not that I know of. My workflow for windows is the same -- commit, watch
the bots, make a guess-based fix if bots got broken.
That's unfortunate, I would rather prefer trybots, but we don't have them
for any platform...

--kcc


>
> On Mon, Apr 25, 2016 at 6:59 PM, Kostya Serebryany  wrote:
>
>> Hopefully fixed by r267513.
>>
>> On Mon, Apr 25, 2016 at 6:46 PM, Kostya Serebryany 
>> wrote:
>>
>>> +rnk
>>>
>>> On Mon, Apr 25, 2016 at 5:09 PM, Jacques Pienaar via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: jpienaar
 Date: Mon Apr 25 19:09:29 2016
 New Revision: 267496

 URL: http://llvm.org/viewvc/llvm-project?rev=267496&view=rev
 Log:
 [lanai] Update handling of structs in arguments to be passed in
 registers.

 Previously aggregate types were passed byval, change the ABI to pass
 these in registers instead.


 Modified:
 cfe/trunk/lib/CodeGen/TargetInfo.cpp
 cfe/trunk/test/CodeGen/lanai-arguments.c

 Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=267496&r1=267495&r2=267496&view=diff

 ==
 --- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
 +++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Mon Apr 25 19:09:29 2016
 @@ -6691,6 +6691,7 @@ public:
I.info = classifyArgumentType(I.type, State);
}

 +  ABIArgInfo getIndirectResult(QualType Ty, bool ByVal, CCState
 &State) const;
ABIArgInfo classifyArgumentType(QualType RetTy, CCState &State)
 const;
  };
  } // end anonymous namespace
 @@ -6712,21 +6713,72 @@ bool LanaiABIInfo::shouldUseInReg(QualTy
return true;
  }

 +ABIArgInfo LanaiABIInfo::getIndirectResult(QualType Ty, bool ByVal,
 +   CCState &State) const {
 +  if (!ByVal) {
 +if (State.FreeRegs) {
 +  --State.FreeRegs; // Non-byval indirects just use one pointer.
 +  return getNaturalAlignIndirectInReg(Ty);
 +}
 +return getNaturalAlignIndirect(Ty, false);
 +  }
 +
 +  // Compute the byval alignment.
 +  constexpr unsigned MinABIStackAlignInBytes = 4;

>>>
>>> This broke the build on Windows;
>>>
>>> C:\b\slave\sanitizer-windows\llvm\tools\clang\lib\CodeGen\TargetInfo.cpp(6727)
>>>  : error C2065: 'constexpr' : undeclared identifier
>>>
>>>
>>>
>>>
>>>
 +  unsigned TypeAlign = getContext().getTypeAlign(Ty) / 8;
 +  return ABIArgInfo::getIndirect(CharUnits::fromQuantity(4),
 /*ByVal=*/true,
 + /*Realign=*/TypeAlign >
 + MinABIStackAlignInBytes);
 +}
 +
  ABIArgInfo LanaiABIInfo::classifyArgumentType(QualType Ty,
CCState &State) const {
 -  if (isAggregateTypeForABI(Ty))
 -return getNaturalAlignIndirect(Ty);
 +  // Check with the C++ ABI first.
 +  const RecordType *RT = Ty->getAs();
 +  if (RT) {
 +CGCXXABI::RecordArgABI RAA = getRecordArgABI(RT, getCXXABI());
 +if (RAA == CGCXXABI::RAA_Indirect) {
 +  return getIndirectResult(Ty, /*ByVal=*/false, State);
 +} else if (RAA == CGCXXABI::RAA_DirectInMemory) {
 +  return getNaturalAlignIndirect(Ty, /*ByRef=*/true);
 +}
 +  }
 +
 +  if (isAggregateTypeForABI(Ty)) {
 +// Structures with flexible arrays are always indirect.
 +if (RT && RT->getDecl()->hasFlexibleArrayMember())
 +  return getIndirectResult(Ty, /*ByVal=*/true, State);
 +
 +// Ignore empty structs/unions.
 +if (isEmptyRecord(getContext(), Ty, true))
 +  return ABIArgInfo::getIgnore();
 +
 +llvm::LLVMContext &LLVMContext = getVMContext();
 +unsigned SizeInRegs = (getContext().getTypeSize(Ty) + 31) / 32;
 +if (SizeInRegs <= State.FreeRegs) {
 +  llvm::IntegerType *Int32 = llvm::Type::getInt32Ty(LLVMContext);
 +  SmallVector Elements(SizeInRegs, Int32);
 +  llvm::Type *Result = llvm::StructType::get(LLVMContext,
 Elements);
 +  State.FreeRegs -= SizeInRegs;
 +  return ABIArgInfo::getDirectInReg(Result);
 +} else {
 +  State.FreeRegs = 0;
 +}
 +return getIndirectResult(Ty, true, State);
 +  }

// Treat an enum type as its underlying type.
if (const auto *EnumTy = Ty->getAs())
  Ty = EnumTy->getDecl()->getIntegerType();

 -  if (shouldUseInReg(Ty, State))
 -r

r268540 - document -f[no-]sanitize-recover=all and mention it in warning messages

2016-05-04 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Wed May  4 15:21:47 2016
New Revision: 268540

URL: http://llvm.org/viewvc/llvm-project?rev=268540&view=rev
Log:
document -f[no-]sanitize-recover=all and mention it in warning messages

Modified:
cfe/trunk/docs/UsersManual.rst
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/test/Driver/fsanitize.c

Modified: cfe/trunk/docs/UsersManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=268540&r1=268539&r2=268540&view=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Wed May  4 15:21:47 2016
@@ -985,6 +985,7 @@ are listed below.
program.
 
 **-f[no-]sanitize-recover=check1,check2,...**
+**-f[no-]sanitize-recover=all**
 
Controls which checks enabled by ``-fsanitize=`` flag are non-fatal.
If the check is fatal, program will halt after the first error

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=268540&r1=268539&r2=268540&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Wed May  4 15:21:47 2016
@@ -340,11 +340,13 @@ SanitizerArgs::SanitizerArgs(const ToolC
   for (const auto *Arg : Args) {
 const char *DeprecatedReplacement = nullptr;
 if (Arg->getOption().matches(options::OPT_fsanitize_recover)) {
-  DeprecatedReplacement = "-fsanitize-recover=undefined,integer";
+  DeprecatedReplacement =
+  "-fsanitize-recover=undefined,integer' or '-fsanitize-recover=all";
   RecoverableKinds |= expandSanitizerGroups(LegacyFsanitizeRecoverMask);
   Arg->claim();
 } else if (Arg->getOption().matches(options::OPT_fno_sanitize_recover)) {
-  DeprecatedReplacement = "-fno-sanitize-recover=undefined,integer";
+  DeprecatedReplacement = "-fno-sanitize-recover=undefined,integer' or "
+  "'-fno-sanitize-recover=all";
   RecoverableKinds &= ~expandSanitizerGroups(LegacyFsanitizeRecoverMask);
   Arg->claim();
 } else if (Arg->getOption().matches(options::OPT_fsanitize_recover_EQ)) {

Modified: cfe/trunk/test/Driver/fsanitize.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize.c?rev=268540&r1=268539&r2=268540&view=diff
==
--- cfe/trunk/test/Driver/fsanitize.c (original)
+++ cfe/trunk/test/Driver/fsanitize.c Wed May  4 15:21:47 2016
@@ -196,8 +196,8 @@
 // CHECK-DIAG-RECOVER: unsupported argument 'unreachable' to option 
'fsanitize-recover='
 
 // RUN: %clang -target x86_64-linux-gnu %s -fsanitize=undefined 
-fsanitize-recover -fno-sanitize-recover -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-DEPRECATED-RECOVER
-// CHECK-DEPRECATED-RECOVER: argument '-fsanitize-recover' is deprecated, use 
'-fsanitize-recover=undefined,integer' instead
-// CHECK-DEPRECATED-RECOVER: argument '-fno-sanitize-recover' is deprecated, 
use '-fno-sanitize-recover=undefined,integer' instead
+// CHECK-DEPRECATED-RECOVER: argument '-fsanitize-recover' is deprecated, use 
'-fsanitize-recover=undefined,integer' or '-fsanitize-recover=all' instead
+// CHECK-DEPRECATED-RECOVER: argument '-fno-sanitize-recover' is deprecated, 
use '-fno-sanitize-recover=undefined,integer' or '-fno-sanitize-recover=all' 
instead
 // CHECK-DEPRECATED-RECOVER-NOT: is deprecated
 
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-SANL


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


r268541 - fix docs

2016-05-04 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Wed May  4 15:24:54 2016
New Revision: 268541

URL: http://llvm.org/viewvc/llvm-project?rev=268541&view=rev
Log:
fix docs

Modified:
cfe/trunk/docs/UsersManual.rst

Modified: cfe/trunk/docs/UsersManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=268541&r1=268540&r2=268541&view=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Wed May  4 15:24:54 2016
@@ -985,6 +985,7 @@ are listed below.
program.
 
 **-f[no-]sanitize-recover=check1,check2,...**
+
 **-f[no-]sanitize-recover=all**
 
Controls which checks enabled by ``-fsanitize=`` flag are non-fatal.


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


r266672 - [sanitizer-coverage] better docs for -fsanitize-coverage=trace-bb

2016-04-18 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Mon Apr 18 16:28:37 2016
New Revision: 266672

URL: http://llvm.org/viewvc/llvm-project?rev=266672&view=rev
Log:
[sanitizer-coverage] better docs for -fsanitize-coverage=trace-bb

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=266672&r1=266671&r2=266672&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Mon Apr 18 16:28:37 2016
@@ -286,10 +286,26 @@ These counters may also be used for in-p
 
 Tracing basic blocks
 
-An *experimental* feature to support basic block (or edge) tracing.
+Experimental support for basic block (or edge) tracing.
 With ``-fsanitize-coverage=trace-bb`` the compiler will insert
 ``__sanitizer_cov_trace_basic_block(s32 *id)`` before every function, basic 
block, or edge
 (depending on the value of ``-fsanitize-coverage=[func,bb,edge]``).
+Example:
+
+.. code-block:: console
+
+% clang -g -fsanitize=address -fsanitize-coverage=edge,trace-bb foo.cc
+% ASAN_OPTIONS=coverage=1 ./a.out
+
+This will produce two files after the process exit:
+`trace-points.PID.sancov` and `trace-events.PID.sancov`.
+The first file will contain a textual description of all the instrumented 
points in the program
+in the form that you can feed into llvm-symbolizer (e.g. `a.out 0x4dca89`), 
one per line.
+The second file will contain the actual execution trace as a sequence of 
4-byte integers
+-- these integers are the indices into the array of instrumented points (the 
first file).
+
+Basic block tracing is currently supported only for single-threaded 
applications.
+
 
 Tracing PCs
 ===


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


r266673 - [sanitizer-coverage] make sure coverage flags are not passed to clang if the driver thinks they are unused

2016-04-18 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Mon Apr 18 16:30:17 2016
New Revision: 266673

URL: http://llvm.org/viewvc/llvm-project?rev=266673&view=rev
Log:
[sanitizer-coverage] make sure coverage flags are not passed to clang if the 
driver thinks they are unused

Modified:
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=266673&r1=266672&r2=266673&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Mon Apr 18 16:30:17 2016
@@ -482,6 +482,8 @@ SanitizerArgs::SanitizerArgs(const ToolC
   if ((CoverageFeatures & CoverageTracePC) ||
   (AllAddedKinds & SupportsCoverage)) {
 Arg->claim();
+  } else {
+CoverageFeatures = 0;
   }
 } else if (Arg->getOption().matches(options::OPT_fno_sanitize_coverage)) {
   Arg->claim();

Modified: cfe/trunk/test/Driver/fsanitize-coverage.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize-coverage.c?rev=266673&r1=266672&r2=266673&view=diff
==
--- cfe/trunk/test/Driver/fsanitize-coverage.c (original)
+++ cfe/trunk/test/Driver/fsanitize-coverage.c Mon Apr 18 16:30:17 2016
@@ -35,6 +35,7 @@
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=thread   
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-UNUSED
 // RUN: %clang -target x86_64-linux-gnu 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-UNUSED
 // CHECK-SANITIZE-COVERAGE-UNUSED: argument unused during compilation: 
'-fsanitize-coverage=func'
+// CHECK-SANITIZE-COVERAGE-UNUSED-NOT: -fsanitize-coverage-type=1
 
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=func -fno-sanitize=address %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-SAN-DISABLED
 // CHECK-SANITIZE-COVERAGE-SAN-DISABLED-NOT: argument unused


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


Re: r267496 - [lanai] Update handling of structs in arguments to be passed in registers.

2016-04-25 Thread Kostya Serebryany via cfe-commits
+rnk

On Mon, Apr 25, 2016 at 5:09 PM, Jacques Pienaar via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: jpienaar
> Date: Mon Apr 25 19:09:29 2016
> New Revision: 267496
>
> URL: http://llvm.org/viewvc/llvm-project?rev=267496&view=rev
> Log:
> [lanai] Update handling of structs in arguments to be passed in registers.
>
> Previously aggregate types were passed byval, change the ABI to pass these
> in registers instead.
>
>
> Modified:
> cfe/trunk/lib/CodeGen/TargetInfo.cpp
> cfe/trunk/test/CodeGen/lanai-arguments.c
>
> Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=267496&r1=267495&r2=267496&view=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Mon Apr 25 19:09:29 2016
> @@ -6691,6 +6691,7 @@ public:
>I.info = classifyArgumentType(I.type, State);
>}
>
> +  ABIArgInfo getIndirectResult(QualType Ty, bool ByVal, CCState &State)
> const;
>ABIArgInfo classifyArgumentType(QualType RetTy, CCState &State) const;
>  };
>  } // end anonymous namespace
> @@ -6712,21 +6713,72 @@ bool LanaiABIInfo::shouldUseInReg(QualTy
>return true;
>  }
>
> +ABIArgInfo LanaiABIInfo::getIndirectResult(QualType Ty, bool ByVal,
> +   CCState &State) const {
> +  if (!ByVal) {
> +if (State.FreeRegs) {
> +  --State.FreeRegs; // Non-byval indirects just use one pointer.
> +  return getNaturalAlignIndirectInReg(Ty);
> +}
> +return getNaturalAlignIndirect(Ty, false);
> +  }
> +
> +  // Compute the byval alignment.
> +  constexpr unsigned MinABIStackAlignInBytes = 4;
>

This broke the build on Windows;

C:\b\slave\sanitizer-windows\llvm\tools\clang\lib\CodeGen\TargetInfo.cpp(6727)
: error C2065: 'constexpr' : undeclared identifier





> +  unsigned TypeAlign = getContext().getTypeAlign(Ty) / 8;
> +  return ABIArgInfo::getIndirect(CharUnits::fromQuantity(4),
> /*ByVal=*/true,
> + /*Realign=*/TypeAlign >
> + MinABIStackAlignInBytes);
> +}
> +
>  ABIArgInfo LanaiABIInfo::classifyArgumentType(QualType Ty,
>CCState &State) const {
> -  if (isAggregateTypeForABI(Ty))
> -return getNaturalAlignIndirect(Ty);
> +  // Check with the C++ ABI first.
> +  const RecordType *RT = Ty->getAs();
> +  if (RT) {
> +CGCXXABI::RecordArgABI RAA = getRecordArgABI(RT, getCXXABI());
> +if (RAA == CGCXXABI::RAA_Indirect) {
> +  return getIndirectResult(Ty, /*ByVal=*/false, State);
> +} else if (RAA == CGCXXABI::RAA_DirectInMemory) {
> +  return getNaturalAlignIndirect(Ty, /*ByRef=*/true);
> +}
> +  }
> +
> +  if (isAggregateTypeForABI(Ty)) {
> +// Structures with flexible arrays are always indirect.
> +if (RT && RT->getDecl()->hasFlexibleArrayMember())
> +  return getIndirectResult(Ty, /*ByVal=*/true, State);
> +
> +// Ignore empty structs/unions.
> +if (isEmptyRecord(getContext(), Ty, true))
> +  return ABIArgInfo::getIgnore();
> +
> +llvm::LLVMContext &LLVMContext = getVMContext();
> +unsigned SizeInRegs = (getContext().getTypeSize(Ty) + 31) / 32;
> +if (SizeInRegs <= State.FreeRegs) {
> +  llvm::IntegerType *Int32 = llvm::Type::getInt32Ty(LLVMContext);
> +  SmallVector Elements(SizeInRegs, Int32);
> +  llvm::Type *Result = llvm::StructType::get(LLVMContext, Elements);
> +  State.FreeRegs -= SizeInRegs;
> +  return ABIArgInfo::getDirectInReg(Result);
> +} else {
> +  State.FreeRegs = 0;
> +}
> +return getIndirectResult(Ty, true, State);
> +  }
>
>// Treat an enum type as its underlying type.
>if (const auto *EnumTy = Ty->getAs())
>  Ty = EnumTy->getDecl()->getIntegerType();
>
> -  if (shouldUseInReg(Ty, State))
> -return ABIArgInfo::getDirectInReg();
> -
> -  if (Ty->isPromotableIntegerType())
> +  bool InReg = shouldUseInReg(Ty, State);
> +  if (Ty->isPromotableIntegerType()) {
> +if (InReg)
> +  return ABIArgInfo::getDirectInReg();
>  return ABIArgInfo::getExtend();
> -
> +  }
> +  if (InReg)
> +return ABIArgInfo::getDirectInReg();
>return ABIArgInfo::getDirect();
>  }
>
>
> Modified: cfe/trunk/test/CodeGen/lanai-arguments.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/lanai-arguments.c?rev=267496&r1=267495&r2=267496&view=diff
>
> ==
> --- cfe/trunk/test/CodeGen/lanai-arguments.c (original)
> +++ cfe/trunk/test/CodeGen/lanai-arguments.c Mon Apr 25 19:09:29 2016
> @@ -10,7 +10,7 @@ typedef struct {
>int aa;
>int bb;
>  } s1;
> -// CHECK: define void @f1(%struct.s1* byval align 4 %i)
> +// CHECK: define void @f1(i32 inreg %i.coerce0, i32 inreg %i.coerce1)
>  void f1(s1 i) {}
>
>  typedef struct {
>

r267513 - trying to fix the windows build broken by r267496

2016-04-25 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Mon Apr 25 20:53:49 2016
New Revision: 267513

URL: http://llvm.org/viewvc/llvm-project?rev=267513&view=rev
Log:
trying to fix the windows build broken by r267496

Modified:
cfe/trunk/lib/CodeGen/TargetInfo.cpp

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=267513&r1=267512&r2=267513&view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Mon Apr 25 20:53:49 2016
@@ -6724,7 +6724,7 @@ ABIArgInfo LanaiABIInfo::getIndirectResu
   }
 
   // Compute the byval alignment.
-  constexpr unsigned MinABIStackAlignInBytes = 4;
+  const unsigned MinABIStackAlignInBytes = 4;
   unsigned TypeAlign = getContext().getTypeAlign(Ty) / 8;
   return ABIArgInfo::getIndirect(CharUnits::fromQuantity(4), /*ByVal=*/true,
  /*Realign=*/TypeAlign >


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


Re: r267496 - [lanai] Update handling of structs in arguments to be passed in registers.

2016-04-25 Thread Kostya Serebryany via cfe-commits
Hopefully fixed by r267513.

On Mon, Apr 25, 2016 at 6:46 PM, Kostya Serebryany  wrote:

> +rnk
>
> On Mon, Apr 25, 2016 at 5:09 PM, Jacques Pienaar via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: jpienaar
>> Date: Mon Apr 25 19:09:29 2016
>> New Revision: 267496
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=267496&view=rev
>> Log:
>> [lanai] Update handling of structs in arguments to be passed in registers.
>>
>> Previously aggregate types were passed byval, change the ABI to pass
>> these in registers instead.
>>
>>
>> Modified:
>> cfe/trunk/lib/CodeGen/TargetInfo.cpp
>> cfe/trunk/test/CodeGen/lanai-arguments.c
>>
>> Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=267496&r1=267495&r2=267496&view=diff
>>
>> ==
>> --- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Mon Apr 25 19:09:29 2016
>> @@ -6691,6 +6691,7 @@ public:
>>I.info = classifyArgumentType(I.type, State);
>>}
>>
>> +  ABIArgInfo getIndirectResult(QualType Ty, bool ByVal, CCState &State)
>> const;
>>ABIArgInfo classifyArgumentType(QualType RetTy, CCState &State) const;
>>  };
>>  } // end anonymous namespace
>> @@ -6712,21 +6713,72 @@ bool LanaiABIInfo::shouldUseInReg(QualTy
>>return true;
>>  }
>>
>> +ABIArgInfo LanaiABIInfo::getIndirectResult(QualType Ty, bool ByVal,
>> +   CCState &State) const {
>> +  if (!ByVal) {
>> +if (State.FreeRegs) {
>> +  --State.FreeRegs; // Non-byval indirects just use one pointer.
>> +  return getNaturalAlignIndirectInReg(Ty);
>> +}
>> +return getNaturalAlignIndirect(Ty, false);
>> +  }
>> +
>> +  // Compute the byval alignment.
>> +  constexpr unsigned MinABIStackAlignInBytes = 4;
>>
>
> This broke the build on Windows;
>
> C:\b\slave\sanitizer-windows\llvm\tools\clang\lib\CodeGen\TargetInfo.cpp(6727)
>  : error C2065: 'constexpr' : undeclared identifier
>
>
>
>
>
>> +  unsigned TypeAlign = getContext().getTypeAlign(Ty) / 8;
>> +  return ABIArgInfo::getIndirect(CharUnits::fromQuantity(4),
>> /*ByVal=*/true,
>> + /*Realign=*/TypeAlign >
>> + MinABIStackAlignInBytes);
>> +}
>> +
>>  ABIArgInfo LanaiABIInfo::classifyArgumentType(QualType Ty,
>>CCState &State) const {
>> -  if (isAggregateTypeForABI(Ty))
>> -return getNaturalAlignIndirect(Ty);
>> +  // Check with the C++ ABI first.
>> +  const RecordType *RT = Ty->getAs();
>> +  if (RT) {
>> +CGCXXABI::RecordArgABI RAA = getRecordArgABI(RT, getCXXABI());
>> +if (RAA == CGCXXABI::RAA_Indirect) {
>> +  return getIndirectResult(Ty, /*ByVal=*/false, State);
>> +} else if (RAA == CGCXXABI::RAA_DirectInMemory) {
>> +  return getNaturalAlignIndirect(Ty, /*ByRef=*/true);
>> +}
>> +  }
>> +
>> +  if (isAggregateTypeForABI(Ty)) {
>> +// Structures with flexible arrays are always indirect.
>> +if (RT && RT->getDecl()->hasFlexibleArrayMember())
>> +  return getIndirectResult(Ty, /*ByVal=*/true, State);
>> +
>> +// Ignore empty structs/unions.
>> +if (isEmptyRecord(getContext(), Ty, true))
>> +  return ABIArgInfo::getIgnore();
>> +
>> +llvm::LLVMContext &LLVMContext = getVMContext();
>> +unsigned SizeInRegs = (getContext().getTypeSize(Ty) + 31) / 32;
>> +if (SizeInRegs <= State.FreeRegs) {
>> +  llvm::IntegerType *Int32 = llvm::Type::getInt32Ty(LLVMContext);
>> +  SmallVector Elements(SizeInRegs, Int32);
>> +  llvm::Type *Result = llvm::StructType::get(LLVMContext, Elements);
>> +  State.FreeRegs -= SizeInRegs;
>> +  return ABIArgInfo::getDirectInReg(Result);
>> +} else {
>> +  State.FreeRegs = 0;
>> +}
>> +return getIndirectResult(Ty, true, State);
>> +  }
>>
>>// Treat an enum type as its underlying type.
>>if (const auto *EnumTy = Ty->getAs())
>>  Ty = EnumTy->getDecl()->getIntegerType();
>>
>> -  if (shouldUseInReg(Ty, State))
>> -return ABIArgInfo::getDirectInReg();
>> -
>> -  if (Ty->isPromotableIntegerType())
>> +  bool InReg = shouldUseInReg(Ty, State);
>> +  if (Ty->isPromotableIntegerType()) {
>> +if (InReg)
>> +  return ABIArgInfo::getDirectInReg();
>>  return ABIArgInfo::getExtend();
>> -
>> +  }
>> +  if (InReg)
>> +return ABIArgInfo::getDirectInReg();
>>return ABIArgInfo::getDirect();
>>  }
>>
>>
>> Modified: cfe/trunk/test/CodeGen/lanai-arguments.c
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/lanai-arguments.c?rev=267496&r1=267495&r2=267496&view=diff
>>
>> ==
>> --- cfe/trunk/test/CodeGen/lanai-arguments.c (original)
>> +++ cfe/trunk/test/CodeGen/lanai-arguments.c Mon Apr 25 19:09:29 2016
>> @@ -10,7 +1

r271005 - [msan] add a sentence about inline assembly

2016-05-27 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Fri May 27 10:49:32 2016
New Revision: 271005

URL: http://llvm.org/viewvc/llvm-project?rev=271005&view=rev
Log:
[msan] add a sentence about inline assembly

Modified:
cfe/trunk/docs/MemorySanitizer.rst

Modified: cfe/trunk/docs/MemorySanitizer.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/MemorySanitizer.rst?rev=271005&r1=271004&r2=271005&view=diff
==
--- cfe/trunk/docs/MemorySanitizer.rst (original)
+++ cfe/trunk/docs/MemorySanitizer.rst Fri May 27 10:49:32 2016
@@ -171,6 +171,8 @@ Handling external code
 MemorySanitizer requires that all program code is instrumented. This
 also includes any libraries that the program depends on, even libc.
 Failing to achieve this may result in false reports.
+For the same reason you may need to replace all inline assembly code that 
writes to memory
+with a pure C/C++ code.
 
 Full MemorySanitizer instrumentation is very difficult to achieve. To
 make it easier, MemorySanitizer runtime library includes 70+


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


Re: [PATCH] D21317: [sanitizer] Allow sanitize coverage w/o sanitizers.

2016-06-14 Thread Kostya Serebryany via cfe-commits
kcc added a comment.

What run-time is going to be linked when coverage is used w/o any of the 
sanitizers?


Repository:
  rL LLVM

http://reviews.llvm.org/D21317



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


Re: [PATCH] D21317: [sanitizer] Allow sanitize coverage w/o sanitizers.

2016-06-14 Thread Kostya Serebryany via cfe-commits
kcc added a comment.

Can you at least add a compiler-rt test where we ensure that this flag can not 
be used such that it wil compile but fail to link?

E.g.

  clang -fsanitize-coverage=edge x.c 

should compile *and* link (and run)


Repository:
  rL LLVM

http://reviews.llvm.org/D21317



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


Re: [PATCH] D21317: [sanitizer] Allow sanitize coverage w/o sanitizers.

2016-06-14 Thread Kostya Serebryany via cfe-commits
kcc accepted this revision.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM
Please also check if the documentation needs to be updated.


Repository:
  rL LLVM

http://reviews.llvm.org/D21317



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


Re: [PATCH] D21446: Comprehensive static instrumentation (2/3): Clang support

2016-06-16 Thread Kostya Serebryany via cfe-commits
kcc added inline comments.


Comment at: docs/CSI.rst:7
@@ +6,3 @@
+
+CSI:LLVM is a framework providing comprehensive static instrumentation via the
+compiler in order to simplify the task of building efficient and effective

The intro paragraph is important to attract users. 
That's up to you, but I would try to make it shorter. 
E.g. 
"framework providing comprehensive static instrumentation via the compiler"
might be replaced with 
"framework for comprehensive compile-time instrumentation"
etc. 

On the other hand, the intro lacks a single most important sentence, in bold, 
explaining why CSI is cool. Something like "With CSI the tool writers will not 
need to hack the compiler"


Comment at: docs/CSI.rst:22
@@ +21,3 @@
+To ensure high performance of CSI tools, CSI:LLVM ideally should be configured
+to enable link-time optimization (LTO), and the GNU ``gold linker`` is a
+prerequisite for enabling LTO for CSI:LLVM.  (See

gold is not the only linker that supports LTO. 
Say something like "linker needs to support LTO [link]"


Comment at: docs/CSI.rst:29
@@ +28,3 @@
+
+To create a CSI tool, add ``#include `` at the top of the tool source
+and implement function bodies for the hooks relevant to the tool.

Here you may want a bit more detail. 
E.g. "a simple CSI tool may consist of a single C++ file".  


Comment at: docs/CSI.rst:38
@@ +37,3 @@
+
+  % clang++ -c -emit-llvm null-tool.c -o null-tool.o
+  % clang++ -c -emit-llvm my-tool.cpp -o my-tool.o

-emit-llvm here is confusing, at least for me. 
Either explain why you need it here (to combine real object file with LLVM) or 
find another way...

Ideally, this and linking the null tool should be hidden under -fcsi or some 
such,
but this could be done in later patches. 


Comment at: docs/CSI.rst:48
@@ +47,3 @@
+
+The LLVM/Clang used to build the tool does not have to be CSI:LLVM, as long
+as it generates LLVM bitcode compatible with CSI:LLVM.

Even if this is true, the statement is a bit risky. 
What if the LLVM bit code changes? 
I would omit this unless you really need it. 


Comment at: docs/CSI.rst:58
@@ +57,3 @@
+
+* Modify paths in the build process to point to CSI:LLVM (including its Clang
+  driver).

Too complex. Just tell the user that they need to use fresh clang. 


Comment at: docs/CSI.rst:61
@@ +60,3 @@
+* When building object files for the TIX, pass additional arguments ``-fcsi``
+  and ``-emit-llvm`` to the Clang driver, which produces CSI instrumented
+  object files.

-emit-llvm again. It should be hidden inside -fcsi. 
It's ok to fix it later, but then please explain in the docs that it's temporary


Comment at: docs/CSI.rst:64
@@ +63,3 @@
+* During the linking stage for the TIX, add additional arguments
+  ``-fuse-ld=gold`` and ``-flto`` and add the tool object file (e.g.
+  ``my-tool.o``) to be statically linked to the TIX.

again, gold is not the only LTO-enabled linker. 


Comment at: docs/CSI.rst:79
@@ +78,3 @@
+the static library of the CSI runtime to produce the final TIX.  The runtime
+archive is distributed under the ``build/lib/clang//lib/``
+directory. We plan to investigate means of linking with the runtime

this too needs to be hidden under -fcsi


Comment at: docs/CSI.rst:125
@@ +124,3 @@
+  // Value representing unknown CSI ID
+  #define UNKNOWN_CSI_ID ((csi_id_t)-1)
+

avoid the C preprocessor when you can (const var is usually better)


Comment at: docs/CSI.rst:148
@@ +147,3 @@
+``init_priority`` attribute), however, the execution order of that constructor
+relative to ``__csi_init`` is undefined.
+

On Linux, there is preinit_array... Just saying... 


Comment at: docs/CSI.rst:196
@@ +195,3 @@
+
+ void __csi_bb_entry(const csi_id_t bb_id);
+ void __csi_bb_exit(const csi_id_t bb_id);

didn't you want properties here? 
E.g. I have one use case for bb_entry property: whether this BB is important 
for coverage instrumentation or may be omitted. 

(there are plenty of papers on this, e.g. 
http://users.sdsc.edu/~mtikir/publications/papers/issta02.pdf)


Comment at: docs/CSI.rst:216
@@ +215,3 @@
+
+  void __csi_before_call(const csi_id_t call_id, const csi_id_t func_id);
+  void __csi_after_call(const csi_id_t call_id, const csi_id_t func_id);

maybe use callee_id instead of func_id?


Comment at: docs/CSI.rst:245
@@ +244,3 @@
+  // the same basic block.
+  #define CSI_PROP_LOAD_READ_BEFORE_WRITE_IN_BB 0x1
+

avoid #defines.
const or enum should be enough


Comment at: docs/CSI.rst:266
@@ +265,3 @@
+locations in the source code.  The FED tables are indexed by the progr

r262503 - [libFuzzer] allow -fsanitize-coverage=0 (disables all coverage)

2016-03-02 Thread Kostya Serebryany via cfe-commits
Author: kcc
Date: Wed Mar  2 13:16:54 2016
New Revision: 262503

URL: http://llvm.org/viewvc/llvm-project?rev=262503&view=rev
Log:
[libFuzzer] allow -fsanitize-coverage=0 (disables all coverage)

Modified:
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=262503&r1=262502&r2=262503&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Wed Mar  2 13:16:54 2016
@@ -446,9 +446,8 @@ SanitizerArgs::SanitizerArgs(const ToolC
   LegacySanitizeCoverage >= 0 && LegacySanitizeCoverage <= 4) {
 switch (LegacySanitizeCoverage) {
 case 0:
-  D.Diag(diag::warn_drv_deprecated_arg) << Arg->getAsString(Args)
-<< "-fsanitize-coverage=";
   CoverageFeatures = 0;
+  Arg->claim();
   break;
 case 1:
   D.Diag(diag::warn_drv_deprecated_arg) << Arg->getAsString(Args)

Modified: cfe/trunk/test/Driver/fsanitize-coverage.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize-coverage.c?rev=262503&r1=262502&r2=262503&view=diff
==
--- cfe/trunk/test/Driver/fsanitize-coverage.c (original)
+++ cfe/trunk/test/Driver/fsanitize-coverage.c Wed Mar  2 13:16:54 2016
@@ -2,6 +2,7 @@
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=edge -fsanitize-coverage=0 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-0
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-SANITIZE-COVERAGE-0
 // CHECK-SANITIZE-COVERAGE-0-NOT: fsanitize-coverage-type
+// CHECK-SANITIZE-COVERAGE-0: -fsanitize=address
 
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=memory 
-fsanitize-coverage=func %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-FUNC
@@ -21,6 +22,10 @@
 // CHECK-SANITIZE-COVERAGE-FUNC_INDIR: fsanitize-coverage-type=3
 // CHECK-SANITIZE-COVERAGE-FUNC_INDIR: fsanitize-coverage-indirect-calls
 
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=1 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-1
+// CHECK-SANITIZE-COVERAGE-1: warning: argument '-fsanitize-coverage=1' is 
deprecated, use '-fsanitize-coverage=func' instead
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=2 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-2
+// CHECK-SANITIZE-COVERAGE-2: warning: argument '-fsanitize-coverage=2' is 
deprecated, use '-fsanitize-coverage=bb' instead
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-coverage=3 %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANITIZE-COVERAGE-3
 // CHECK-SANITIZE-COVERAGE-3: warning: argument '-fsanitize-coverage=3' is 
deprecated, use '-fsanitize-coverage=edge' instead
 //


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


Re: r263687 - Add an optional named argument (replacement = "xxx") to AvailabilityAttr.

2016-03-19 Thread Kostya Serebryany via cfe-commits
This change is causing ubsan bot to complain

.
Please fix or revert.

Most likely the guilty part is this:

+*getReplacementSlot() = replacementExpr;

/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/include/clang/Sema/AttributeList.h:276:5:
runtime error: store to misaligned address 0x19b3784c for type
'const clang::Expr *', which requires 8 byte alignment
0x19b3784c: note: pointer points here
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00
00 00  00 00 00 00 00 00 00 00  ^
#0 0x448295e in
clang::AttributeList::AttributeList(clang::IdentifierInfo*,
clang::SourceRange, clang::IdentifierInfo*, clang::SourceLocation,
clang::IdentifierLoc*, clang::AvailabilityChange const&,
clang::AvailabilityChange const&, clang::AvailabilityChange const&,
clang::SourceLocation, clang::Expr const*,
clang::AttributeList::Syntax, clang::SourceLocation, clang::Expr
const*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/include/clang/Sema/AttributeList.h:276:27
#1 0x448269c in
clang::AttributePool::create(clang::IdentifierInfo*,
clang::SourceRange, clang::IdentifierInfo*, clang::SourceLocation,
clang::IdentifierLoc*, clang::AvailabilityChange const&,
clang::AvailabilityChange const&, clang::AvailabilityChange const&,
clang::SourceLocation, clang::Expr const*,
clang::AttributeList::Syntax, clang::SourceLocation, clang::Expr
const*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/include/clang/Sema/AttributeList.h:662:29
#2 0x447c52d in
clang::ParsedAttributes::addNew(clang::IdentifierInfo*,
clang::SourceRange, clang::IdentifierInfo*, clang::SourceLocation,
clang::IdentifierLoc*, clang::AvailabilityChange const&,
clang::AvailabilityChange const&, clang::AvailabilityChange const&,
clang::SourceLocation, clang::Expr const*,
clang::AttributeList::Syntax, clang::SourceLocation, clang::Expr
const*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/include/clang/Sema/AttributeList.h:798:7
#3 0x4465a73 in clang::Parser::Pa




On Wed, Mar 16, 2016 at 8:09 PM, Manman Ren via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: mren
> Date: Wed Mar 16 22:09:55 2016
> New Revision: 263687
>
> URL: http://llvm.org/viewvc/llvm-project?rev=263687&view=rev
> Log:
> Add an optional named argument (replacement = "xxx") to AvailabilityAttr.
>
> This commit adds a named argument to AvailabilityAttr, while r263652 adds
> an
> optional string argument to __attribute__((deprecated)). This enables the
> compiler to provide Fix-Its for deprecated declarations.
>
> rdar://20588929
>
> Modified:
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Basic/AttrDocs.td
> cfe/trunk/include/clang/Parse/Parser.h
> cfe/trunk/include/clang/Sema/AttributeList.h
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/lib/Lex/PPMacroExpansion.cpp
> cfe/trunk/lib/Parse/ParseDecl.cpp
> cfe/trunk/lib/Parse/Parser.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/test/SemaCXX/attr-deprecated-replacement-fixit.cpp
>
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=263687&r1=263686&r2=263687&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Wed Mar 16 22:09:55 2016
> @@ -467,7 +467,7 @@ def Availability : InheritableAttr {
>let Args = [IdentifierArgument<"platform">,
> VersionArgument<"introduced">,
>VersionArgument<"deprecated">, VersionArgument<"obsoleted">,
>BoolArgument<"unavailable">, StringArgument<"message">,
> -  BoolArgument<"strict">];
> +  BoolArgument<"strict">, StringArgument<"replacement">];
>let AdditionalMembers =
>  [{static llvm::StringRef getPrettyPlatformName(llvm::StringRef Platform) {
>  return llvm::StringSwitch(Platform)
>
> Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=263687&r1=263686&r2=263687&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
> +++ cfe/trunk/include/clang/Basic/AttrDocs.td Wed Mar 16 22:09:55 2016
> @@ -661,6 +661,11 @@ message=\ *string-literal*
>error about use of a deprecated or obsoleted declaration.  Useful to
> direct
>users to replacement APIs.
>
> +replacement=\ *string-literal*
> +  Additional message text that Clang will use to provide Fix-It when
> emitting
> +  a warning about use of a deprecated declaration. The Fix-It will replace
> + 

Re: [clang-tools-extra] r256562 - [clang-tidy] Fix a use-after-free bug found by asan

2016-01-04 Thread Kostya Serebryany via cfe-commits
Nice!
is a fuzzer for clang-tidy possible/desirable?
similar to what we have for clang and clang-format
(tools/clang-format/fuzzer, ./tools/clang-fuzzer)


On Tue, Dec 29, 2015 at 8:14 AM, Alexander Kornienko via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: alexfh
> Date: Tue Dec 29 10:14:38 2015
> New Revision: 256562
>
> URL: http://llvm.org/viewvc/llvm-project?rev=256562&view=rev
> Log:
> [clang-tidy] Fix a use-after-free bug found by asan
>
> Modified:
>
> clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp?rev=256562&r1=256561&r2=256562&view=diff
>
> ==
> ---
> clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp
> (original)
> +++
> clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp
> Tue Dec 29 10:14:38 2015
> @@ -491,9 +491,10 @@ void SimplifyBooleanExprCheck::check(con
>  bool containsDiscardedTokens(
>  const ast_matchers::MatchFinder::MatchResult &Result,
>  CharSourceRange CharRange) {
> -  StringRef ReplacementText =
> +  std::string ReplacementText =
>Lexer::getSourceText(CharRange, *Result.SourceManager,
> -   Result.Context->getLangOpts()).str();
> +   Result.Context->getLangOpts())
> +  .str();
>Lexer Lex(CharRange.getBegin(), Result.Context->getLangOpts(),
>  ReplacementText.data(), ReplacementText.data(),
>  ReplacementText.data() + ReplacementText.size());
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r255371 - Error on redeclaring with a conflicting asm label and on redeclaring with an asm label after the first ODR-use. Detects problems like the one in PR22830 where gcc and clang both compiled

2016-01-04 Thread Kostya Serebryany via cfe-commits
Thanks for checking, Nick!
+Roland, FYI (recent changes in clang break compilation of all of the
glibc),
similar to https://llvm.org/bugs/show_bug.cgi?id=22830#c1

On Mon, Jan 4, 2016 at 3:21 PM, Nick Lewycky  wrote:

> On 01/04/2016 01:40 PM, Kostya Serebryany wrote:
>
>>
>>
>> On Thu, Dec 17, 2015 at 5:03 PM, Richard Smith > > wrote:
>>
>> On Thu, Dec 17, 2015 at 3:59 PM, Nick Lewycky via cfe-commits
>> mailto:cfe-commits@lists.llvm.org>>
>> wrote:
>>
>> On 12/17/2015 10:47 AM, Kostya Serebryany wrote:
>>
>> I am now observing this error message when building glibc
>> with clang
>> (from trunk):
>> ../include/string.h:101:28: error: cannot apply asm label to
>> function
>> after its first use
>> libc_hidden_builtin_proto (memcpy)
>> (many more instances)
>>
>>
>> Do you think this is a bug in glibc code, or the error
>> message could be
>> more relaxed?
>>
>>
>> Could you email me a .i copy of a failing build? That will help
>> me decide whether it's a bug in the error or in glibc.
>>
>>
>> [sorry for delay,]
>> here is the preprocessed source file from glibc:
>> % clang  ~/tmp/a.i 2>&1 | grep error:
>> ../include/sys/stat.h:16:28: error: cannot apply asm label to function
>> after its first use
>> ../include/sys/stat.h:17:30: error: cannot apply asm label to function
>> after its first use
>> ../include/sys/stat.h:18:28: error: cannot apply asm label to function
>> after its first use
>> ../include/sys/stat.h:19:30: error: cannot apply asm label to function
>> after its first use
>> ...
>>
>>
>> Also PR22830 comment 1 seems relevant here.
>>
>>
>> Probably, but since this is a very recent regression in clang I thought
>> I should report it.
>>
>
> This looks like it's WAI:
>
> 3783extern int __fxstat (int __ver, int __fildes, struct stat
> *__stat_buf)
> 3784 __attribute__ ((__nothrow__ )) ;
> ...
> 3827extern __inline int
> 3828__attribute__ ((__nothrow__ )) fstat (int __fd, struct stat
> *__statbuf)
> 3829{
> 3830  return __fxstat (1, __fd, __statbuf);
> 3831}
> ...
> 3910extern __typeof (__fxstat) __fxstat __asm__ ("" "__GI___fxstat")
> __attribute__ ((visibility ("hidden")));
>
> This is exactly the situation where GCC and Clang will emit a different .o
> file.
>
> Nick
>
> On Fri, Dec 11, 2015 at 1:28 PM, Nick Lewycky via cfe-commits
>> > 
>> >
>> >> wrote:
>>
>>  Author: nicholas
>>  Date: Fri Dec 11 15:28:55 2015
>>  New Revision: 255371
>>
>>  URL:
>> http://llvm.org/viewvc/llvm-project?rev=255371&view=rev
>>  Log:
>>  Error on redeclaring with a conflicting asm label and
>> on redeclaring
>>  with an asm label after the first ODR-use. Detects
>> problems like the
>>  one in PR22830 where gcc and clang both compiled the
>> file but with
>>  different behaviour.
>>
>>  Added:
>>   cfe/trunk/test/Sema/asm-label.c
>>  Modified:
>>   cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>>   cfe/trunk/lib/Sema/SemaDecl.cpp
>>
>>  Modified:
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>>  URL:
>>
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=255371&r1=255370&r2=255371&view=diff
>>
>>
>> ==
>>  ---
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> (original)
>>  +++
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Dec
>> 11
>>  15:28:55 2015
>>  @@ -4259,6 +4259,9 @@ def err_tag_definition_of_typedef
>> : Erro
>>def err_conflicting_types : Error<"conflicting types
>> for %0">;
>>def err_different_pass_object_size_params : Error<
>>  "conflicting pass_object_size attributes on
>> parameters">;
>>  +def err_late_asm_label_name : Error<
>>  +  "cannot apply asm label to
>> %select{variable|function}0 after its
>>  first use">;
>>  +def err_different_asm_label : Error<"conflicting asm
>> label">;
>>def err_nested_redefinition : Error<"nested
>> redefinition of %0">;
>>def err_use_with_wrong_tag : Error<
>>   

Re: r255371 - Error on redeclaring with a conflicting asm label and on redeclaring with an asm label after the first ODR-use. Detects problems like the one in PR22830 where gcc and clang both compiled

2016-01-04 Thread Kostya Serebryany via cfe-commits
On Mon, Jan 4, 2016 at 4:04 PM, Roland McGrath  wrote:

> Kostya, do you remember the exact original case in glibc for 22830 and
> what glibc change fixed it?
>
Sadly, no.
I only know that the code was reduced from the code that was setting these
attributes for strtol.


I vaguely recall the case, but not enough to find the actual change
> and compare it to the new scenarios.
> I suspect that the original case was easy to fix because it was just
> that the hidden_proto magic had been put in the wrong place.
>
> The fstat/__fxstat case is harder.  The original declaration of
> __fxstat and the extern inline (that is, 'extern __inline
> __attribute__ ((__gnu_inline__))') definition of fstat (which calls
> __fxstat) is in the installed header, while the hidden_proto (i.e.
> redeclaration with asm label) is in the wrapper header (and
> necessarily must come after the #include of the installed header).
>
> A GNU extern inline case is one where the rationale I mentioned in
> https://llvm.org/bugs/show_bug.cgi?id=22830#c1 for Clang not being
> able to match GCC's semantics might not really apply: you never need
> to emit the code for fstat before the redeclaration, because you only
> ever inline it and never emit an actual function.
>
> Perhaps there is a defensible reason that Clang really cannot match
> the GNU semantics even for this case.  Regardless, Clang really needs
> to thoroughly document its semantics for every language extension when
> its semantics are not completely identical to the GNU language
> extension's semantics.
>
> If Clang's asm labels extension persists in having semantics
> incompatible with the original semantics of the asm labels extension
> invented by GNU, we might be able to work around it adequately in the
> glibc build just by making sure __USE_EXTERN_INLINES is not defined
> during the build.
>
>
> On Mon, Jan 4, 2016 at 3:39 PM, Kostya Serebryany  wrote:
> > Thanks for checking, Nick!
> > +Roland, FYI (recent changes in clang break compilation of all of the
> > glibc),
> > similar to https://llvm.org/bugs/show_bug.cgi?id=22830#c1
> >
> > On Mon, Jan 4, 2016 at 3:21 PM, Nick Lewycky  wrote:
> >>
> >> On 01/04/2016 01:40 PM, Kostya Serebryany wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Dec 17, 2015 at 5:03 PM, Richard Smith  >>> > wrote:
> >>>
> >>> On Thu, Dec 17, 2015 at 3:59 PM, Nick Lewycky via cfe-commits
> >>> mailto:cfe-commits@lists.llvm.org>>
> >>> wrote:
> >>>
> >>> On 12/17/2015 10:47 AM, Kostya Serebryany wrote:
> >>>
> >>> I am now observing this error message when building glibc
> >>> with clang
> >>> (from trunk):
> >>> ../include/string.h:101:28: error: cannot apply asm label
> to
> >>> function
> >>> after its first use
> >>> libc_hidden_builtin_proto (memcpy)
> >>> (many more instances)
> >>>
> >>>
> >>> Do you think this is a bug in glibc code, or the error
> >>> message could be
> >>> more relaxed?
> >>>
> >>>
> >>> Could you email me a .i copy of a failing build? That will help
> >>> me decide whether it's a bug in the error or in glibc.
> >>>
> >>>
> >>> [sorry for delay,]
> >>> here is the preprocessed source file from glibc:
> >>> % clang  ~/tmp/a.i 2>&1 | grep error:
> >>> ../include/sys/stat.h:16:28: error: cannot apply asm label to function
> >>> after its first use
> >>> ../include/sys/stat.h:17:30: error: cannot apply asm label to function
> >>> after its first use
> >>> ../include/sys/stat.h:18:28: error: cannot apply asm label to function
> >>> after its first use
> >>> ../include/sys/stat.h:19:30: error: cannot apply asm label to function
> >>> after its first use
> >>> ...
> >>>
> >>>
> >>> Also PR22830 comment 1 seems relevant here.
> >>>
> >>>
> >>> Probably, but since this is a very recent regression in clang I thought
> >>> I should report it.
> >>
> >>
> >> This looks like it's WAI:
> >>
> >> 3783extern int __fxstat (int __ver, int __fildes, struct stat
> >> *__stat_buf)
> >> 3784 __attribute__ ((__nothrow__ )) ;
> >> ...
> >> 3827extern __inline int
> >> 3828__attribute__ ((__nothrow__ )) fstat (int __fd, struct stat
> >> *__statbuf)
> >> 3829{
> >> 3830  return __fxstat (1, __fd, __statbuf);
> >> 3831}
> >> ...
> >> 3910extern __typeof (__fxstat) __fxstat __asm__ ("" "__GI___fxstat")
> >> __attribute__ ((visibility ("hidden")));
> >>
> >> This is exactly the situation where GCC and Clang will emit a different
> .o
> >> file.
> >>
> >> Nick
> >>
> >>> On Fri, Dec 11, 2015 at 1:28 PM, Nick Lewycky via
> cfe-commits
> >>>  >>> 
> >>>  >>>
> >>> >> wrote:
> >>>
> >>>  Author: nicholas
> >>>  Date: Fri Dec 11 15:28:55 2015

Re: [clang-tools-extra] r256562 - [clang-tidy] Fix a use-after-free bug found by asan

2016-01-05 Thread Kostya Serebryany via cfe-commits
On Tue, Jan 5, 2016 at 9:01 AM, Alexander Kornienko 
wrote:

> On Mon, Jan 4, 2016 at 7:39 PM, Kostya Serebryany  wrote:
>
>> Nice!
>> is a fuzzer for clang-tidy possible/
>>
>
> Should be no more difficult than clang-fuzzer.
>

Let's do it then?


>
>
>> desirable?
>>
>
> It might be useful to find crashes in clang-tidy earlier than we feed a
> ton of sources to it. Not sure how effective it would be, since most checks
> only do something interesting when a rather complicated pattern is found in
> the code. You can take a look at the tests
> 
> to get an idea.
>
>
>> similar to what we have for clang and clang-format
>> (tools/clang-format/fuzzer, ./tools/clang-fuzzer)
>>
>>
>> On Tue, Dec 29, 2015 at 8:14 AM, Alexander Kornienko via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: alexfh
>>> Date: Tue Dec 29 10:14:38 2015
>>> New Revision: 256562
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=256562&view=rev
>>> Log:
>>> [clang-tidy] Fix a use-after-free bug found by asan
>>>
>>> Modified:
>>>
>>> clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp
>>>
>>> Modified:
>>> clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp?rev=256562&r1=256561&r2=256562&view=diff
>>>
>>> ==
>>> ---
>>> clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp
>>> (original)
>>> +++
>>> clang-tools-extra/trunk/clang-tidy/readability/SimplifyBooleanExprCheck.cpp
>>> Tue Dec 29 10:14:38 2015
>>> @@ -491,9 +491,10 @@ void SimplifyBooleanExprCheck::check(con
>>>  bool containsDiscardedTokens(
>>>  const ast_matchers::MatchFinder::MatchResult &Result,
>>>  CharSourceRange CharRange) {
>>> -  StringRef ReplacementText =
>>> +  std::string ReplacementText =
>>>Lexer::getSourceText(CharRange, *Result.SourceManager,
>>> -   Result.Context->getLangOpts()).str();
>>> +   Result.Context->getLangOpts())
>>> +  .str();
>>>Lexer Lex(CharRange.getBegin(), Result.Context->getLangOpts(),
>>>  ReplacementText.data(), ReplacementText.data(),
>>>  ReplacementText.data() + ReplacementText.size());
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D16065: Fix infinite recursion for invalid declaration

2016-01-11 Thread Kostya Serebryany via cfe-commits
kcc accepted this revision.
kcc added a reviewer: kcc.
kcc added a comment.
This revision is now accepted and ready to land.

LGTM, and thanks!


http://reviews.llvm.org/D16065



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


Re: [PATCH] D14858: Support building tsan on android.

2015-11-20 Thread Kostya Serebryany via cfe-commits
kcc added a comment.

performance is a very strong reason to have tsan linked statically. 
every memory access in the app is instrumented with a function call,
if we make this call go through PLT we'll get significant drop in performance.

This is not a blocker, but I want to explicitly mention it.


http://reviews.llvm.org/D14858



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


  1   2   >