maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Instrumentation/DataFlowSanitizer/call.ll

62 lines
1.7 KiB
LLVM
Raw Normal View History

DataFlowSanitizer; LLVM changes. DataFlowSanitizer is a generalised dynamic data flow analysis. Unlike other Sanitizer tools, this tool is not designed to detect a specific class of bugs on its own. Instead, it provides a generic dynamic data flow analysis framework to be used by clients to help detect application-specific issues within their own code. Differential Revision: http://llvm-reviews.chandlerc.com/D965 llvm-svn: 187923
2013-08-08 06:47:18 +08:00
; RUN: opt < %s -dfsan -S | FileCheck %s
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
Add target triples to all dfsan tests. llvm-svn: 223536
2014-12-06 06:32:30 +08:00
target triple = "x86_64-unknown-linux-gnu"
DataFlowSanitizer; LLVM changes. DataFlowSanitizer is a generalised dynamic data flow analysis. Unlike other Sanitizer tools, this tool is not designed to detect a specific class of bugs on its own. Instead, it provides a generic dynamic data flow analysis framework to be used by clients to help detect application-specific issues within their own code. Differential Revision: http://llvm-reviews.chandlerc.com/D965 llvm-svn: 187923
2013-08-08 06:47:18 +08:00
[DFSan] Remove an overly aggressive assert reported in PR26068. This code has been successfully used to bootstrap libc++ in a no-asserts mode for a very long time, so the code that follows cannot be completely incorrect. I've added a test that shows the current behavior for this kind of code with DFSan. If it is desirable for DFSan to do something special when processing an invoke of a variadic function, it can be added, but we shouldn't keep an assert that we've been ignoring due to release builds anyways. llvm-svn: 262829
2016-03-07 22:05:09 +08:00
; CHECK-LABEL: @__dfsan_arg_tls
; CHECK: = external thread_local(initialexec) global [64 x i16]
; CHECK-LABEL: @__dfsan_retval_tls
; CHECK: = external thread_local(initialexec) global i16
DataFlowSanitizer; LLVM changes. DataFlowSanitizer is a generalised dynamic data flow analysis. Unlike other Sanitizer tools, this tool is not designed to detect a specific class of bugs on its own. Instead, it provides a generic dynamic data flow analysis framework to be used by clients to help detect application-specific issues within their own code. Differential Revision: http://llvm-reviews.chandlerc.com/D965 llvm-svn: 187923
2013-08-08 06:47:18 +08:00
declare i32 @f(i32)
declare float @llvm.sqrt.f32(float)
[DFSan] Remove an overly aggressive assert reported in PR26068. This code has been successfully used to bootstrap libc++ in a no-asserts mode for a very long time, so the code that follows cannot be completely incorrect. I've added a test that shows the current behavior for this kind of code with DFSan. If it is desirable for DFSan to do something special when processing an invoke of a variadic function, it can be added, but we shouldn't keep an assert that we've been ignoring due to release builds anyways. llvm-svn: 262829
2016-03-07 22:05:09 +08:00
; CHECK-LABEL: @"dfs$call"
DataFlowSanitizer; LLVM changes. DataFlowSanitizer is a generalised dynamic data flow analysis. Unlike other Sanitizer tools, this tool is not designed to detect a specific class of bugs on its own. Instead, it provides a generic dynamic data flow analysis framework to be used by clients to help detect application-specific issues within their own code. Differential Revision: http://llvm-reviews.chandlerc.com/D965 llvm-svn: 187923
2013-08-08 06:47:18 +08:00
define i32 @call() {
; CHECK: store{{.*}}__dfsan_arg_tls
DataFlowSanitizer: Prefix the name of each instrumented function with "dfs$". DFSan changes the ABI of each function in the module. This makes it possible for a function with the native ABI to be called with the instrumented ABI, or vice versa, thus possibly invoking undefined behavior. A simple way of statically detecting instances of this problem is to prepend the prefix "dfs$" to the name of each instrumented-ABI function. This will not catch every such problem; in particular function pointers passed across the instrumented-native barrier cannot be used on the other side. These problems could potentially be caught dynamically. Differential Revision: http://llvm-reviews.chandlerc.com/D1373 llvm-svn: 189052
2013-08-23 04:08:08 +08:00
; CHECK: call{{.*}}@"dfs$f"
DataFlowSanitizer; LLVM changes. DataFlowSanitizer is a generalised dynamic data flow analysis. Unlike other Sanitizer tools, this tool is not designed to detect a specific class of bugs on its own. Instead, it provides a generic dynamic data flow analysis framework to be used by clients to help detect application-specific issues within their own code. Differential Revision: http://llvm-reviews.chandlerc.com/D965 llvm-svn: 187923
2013-08-08 06:47:18 +08:00
; CHECK: load{{.*}}__dfsan_retval_tls
%r = call i32 @f(i32 0)
; CHECK-NOT: store{{.*}}__dfsan_arg_tls
%i = call float @llvm.sqrt.f32(float -1.0)
; CHECK: store{{.*}}__dfsan_retval_tls
; CHECK: ret i32
ret i32 %r
}
[DFSan] Remove an overly aggressive assert reported in PR26068. This code has been successfully used to bootstrap libc++ in a no-asserts mode for a very long time, so the code that follows cannot be completely incorrect. I've added a test that shows the current behavior for this kind of code with DFSan. If it is desirable for DFSan to do something special when processing an invoke of a variadic function, it can be added, but we shouldn't keep an assert that we've been ignoring due to release builds anyways. llvm-svn: 262829
2016-03-07 22:05:09 +08:00
declare i32 @__gxx_personality_v0(...)
declare i8* @__cxa_begin_catch(i8*)
declare void @__cxa_end_catch()
declare void @g(...)
; CHECK-LABEL: @"dfs$h"
; CHECK: personality {{.*}} @"dfs$__gxx_personality_v0" {{.*}} {
define i32 @h() personality i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*) {
entry:
; CHECK: invoke void (...) @"dfs$g"(i32 42)
invoke void (...) @g(i32 42)
to label %try.cont unwind label %lpad
lpad:
%0 = landingpad { i8*, i32 }
catch i8* null
%1 = extractvalue { i8*, i32 } %0, 0
; CHECK: store {{.*}} @__dfsan_arg_tls
; CHECK: call {{.*}} @"dfs$__cxa_begin_catch"
; CHECK: load {{.*}} @__dfsan_retval_tls
%2 = tail call i8* @__cxa_begin_catch(i8* %1)
; CHECK: call {{.*}} @"dfs$__cxa_end_catch"
tail call void @__cxa_end_catch()
br label %try.cont
try.cont:
ret i32 0
}