Page MenuHomePhabricator

dvyukov (Dmitry Vyukov)
User

Projects

User does not belong to any projects.

User Details

User Since
Dec 6 2012, 2:31 AM (371 w, 2 d)

Recent Activity

Tue, Jan 7

dvyukov added a comment to D72115: [TSan] Remove side effects from ThreadTid.

You may need another function, or add a consume_uid flag to the current one. But if you will do any changes in this area, please add some comment here as to why we reset user_id, it's indeed tricky.

Tue, Jan 7, 10:15 PM · Restricted Project, Restricted Project
dvyukov added a comment to D72115: [TSan] Remove side effects from ThreadTid.

Hi Julian,

Tue, Jan 7, 1:59 AM · Restricted Project, Restricted Project

Oct 21 2019

dvyukov added a comment to D69208: [asan] Provide an interface to update an allocation stack trace..

FWIW for kernel sanitizers we want an ability to memorize few _additional_ stacks per heap object:
https://bugzilla.kernel.org/show_bug.cgi?id=198437
That's very useful for any kind of asynchronous processing environments that involves tasks, callbacks, thread pools, etc (read - almost all large C/C++ software today) because allocation/free stack may be meaningless and/or other stacks may be crucially important.

Oct 21 2019, 12:57 AM · Restricted Project, Restricted Project
dvyukov added a reviewer for D69208: [asan] Provide an interface to update an allocation stack trace.: irogers.
Oct 21 2019, 12:48 AM · Restricted Project, Restricted Project

Oct 15 2019

dvyukov committed rL374868: tsan: fix Go ppc64le build.
tsan: fix Go ppc64le build
Oct 15 2019, 2:13 AM
dvyukov committed rGcc2f68ea2dc8: tsan: fix Go ppc64le build (authored by dvyukov).
tsan: fix Go ppc64le build
Oct 15 2019, 2:11 AM
dvyukov accepted D68046: Fix Go ppc64le build.

Committed as r374868.
I assumed that Sanitizers project and some reviewers should be been added automatically based on changed paths. But somehow it did not happen.
I would suggest to add more people as reviewers in future, but I guess you don't know whom to add...

Oct 15 2019, 1:58 AM · Restricted Project
dvyukov closed D68046: Fix Go ppc64le build.
Oct 15 2019, 1:58 AM · Restricted Project
dvyukov added a reviewer for D68046: Fix Go ppc64le build: vitalybuka.
Oct 15 2019, 1:23 AM · Restricted Project

Oct 11 2019

dvyukov committed rL374522: Request commit access for dvyukov.
Request commit access for dvyukov
Oct 11 2019, 1:27 AM

Oct 1 2019

dvyukov added reviewers for D68277: fix Go windows build: vitalybuka, rnk.
Oct 1 2019, 8:15 PM
dvyukov accepted D67987: [sanitizer_common] Rename OnPrint to __sanitizer_on_print..
Oct 1 2019, 7:55 PM · Restricted Project

Sep 30 2019

dvyukov added a comment to D68176: Rename tsan_interceptors.cpp into tsan_interceptors_posix.cpp.

It won't break anything. It's like removing -Wall flag.

Sep 30 2019, 11:32 AM · Restricted Project, Restricted Project
dvyukov added a comment to D68176: Rename tsan_interceptors.cpp into tsan_interceptors_posix.cpp.

It should break any attempts to include any system headers like <stdio.h>, <sys/types.h> etc.

Sep 30 2019, 11:04 AM · Restricted Project, Restricted Project

Sep 27 2019

dvyukov added a comment to D68176: Rename tsan_interceptors.cpp into tsan_interceptors_posix.cpp.

This is to prevent accidental inclusion of system headers:

Make sure that non-platform-specific files don't include any system headers.

The original decision was that sanitizer runtimes must not include any:
https://github.com/dvyukov/data-race-test-1/commit/259f05f44
Kostya was the main proponent of this.

Sep 27 2019, 11:38 PM · Restricted Project, Restricted Project
dvyukov added a reviewer for D68176: Rename tsan_interceptors.cpp into tsan_interceptors_posix.cpp: kcc.
Sep 27 2019, 11:38 PM · Restricted Project, Restricted Project

Sep 26 2019

dvyukov added a comment to D67987: [sanitizer_common] Rename OnPrint to __sanitizer_on_print..

For the Go version we have a non-weak declaration without definition. How are we going to roll out the change? We would need to update llvm and the hook implementation atomically. But then I am confused how it works today. We have a non-extern "C" hook definition, so build should be broken for the last year...

Sep 26 2019, 5:19 AM · Restricted Project

Sep 24 2019

dvyukov committed rG88a5bba7b59c: sanitizer_common: fix freebsd build error (authored by dvyukov).
sanitizer_common: fix freebsd build error
Sep 24 2019, 1:30 AM
dvyukov committed rL372698: sanitizer_common: fix freebsd build error.
sanitizer_common: fix freebsd build error
Sep 24 2019, 1:27 AM
dvyukov closed D67928: Fix freebsd build.
Sep 24 2019, 1:27 AM · Restricted Project, Restricted Project
dvyukov accepted D67928: Fix freebsd build.

gotsan.cpp is auto-generated file that it's not checked into the repository, but the fix looks good and I merged a fixed version in:
http://llvm.org/viewvc/llvm-project?view=revision&revision=372698

Sep 24 2019, 1:27 AM · Restricted Project, Restricted Project

Sep 22 2019

dvyukov added a comment to D28596: [compiler-rt] General definition for weak functions..

Turns out this broke an important part of our internal integration because sanitizer::OnPrint become OnPrint, so existing hook stopped working. We are clearly missing some tests.
But exporting and calling a global extern "C" OnPrint does not look OK. All functions need to be either extern "C" and
sanitizer_ prefixed, or in __sanitizer:: namespace.

Sep 22 2019, 12:31 AM · Restricted Project
dvyukov added reviewers for D28596: [compiler-rt] General definition for weak functions.: vitalybuka, morehouse.
Sep 22 2019, 12:26 AM · Restricted Project

Sep 18 2019

dvyukov committed rGd97865e530df: tsan: allow the Go runtime to return multiple stack frames for a single PC (authored by dvyukov).
tsan: allow the Go runtime to return multiple stack frames for a single PC
Sep 18 2019, 2:18 AM
dvyukov closed D67671: compiler-rt/lib/tsan: allow the Go runtime to return multiple stack frames for a single PC.
Sep 18 2019, 2:17 AM · Restricted Project, Restricted Project
dvyukov accepted D67671: compiler-rt/lib/tsan: allow the Go runtime to return multiple stack frames for a single PC.

Perfect!
Submitted in http://llvm.org/viewvc/llvm-project?view=revision&revision=372205

Sep 18 2019, 2:17 AM · Restricted Project, Restricted Project
dvyukov committed rL372205: tsan: allow the Go runtime to return multiple stack frames for a single PC.
tsan: allow the Go runtime to return multiple stack frames for a single PC
Sep 18 2019, 2:16 AM

Sep 17 2019

dvyukov added a comment to D67671: compiler-rt/lib/tsan: allow the Go runtime to return multiple stack frames for a single PC.

Besides the nits, are you sure we reconstruct the list in the right order? :)
Did you test it with the Go counterpart? There is that buildgo.sh script that builds new syso file, which you can copy into Go runtime/race.
It would also be nice to have an output test for inlined frames here:
https://github.com/golang/go/blob/master/src/runtime/race/output_test.go
It needs to go with the updated syso files, but you could use it for testing now.
Fingers crossed nothing broke since last syso update.

Sep 17 2019, 11:53 AM · Restricted Project, Restricted Project

Sep 16 2019

dvyukov accepted D66885: [TSan] Add read/write range interface functions with PC.

Generally looks good to me.

Sep 16 2019, 6:31 AM · Restricted Project, Restricted Project

Aug 29 2019

dvyukov added a comment to D66885: [TSan] Add read/write range interface functions with PC.

In this new test, I see the same issue related to race on stack variables as reported here:
https://github.com/google/sanitizers/issues/1134

Aug 29 2019, 11:39 AM · Restricted Project, Restricted Project

Aug 28 2019

dvyukov added a comment to D66885: [TSan] Add read/write range interface functions with PC.

Re tests. Check test/tsan/ dir, e.g. simple_race.c, stack_race.cc, test/tsan/unaligned_norace.cc. There are not too hard to write, we just need to check it builds, detects a race on the annotation and the PC is used in the stack.

Aug 28 2019, 11:09 AM · Restricted Project, Restricted Project
dvyukov added a comment to D66885: [TSan] Add read/write range interface functions with PC.

Thanks for the background. Good to know.

Aug 28 2019, 11:09 AM · Restricted Project, Restricted Project
dvyukov added a reviewer for D66885: [TSan] Add read/write range interface functions with PC: eugenis.
Aug 28 2019, 11:03 AM · Restricted Project, Restricted Project
dvyukov added a comment to D66885: [TSan] Add read/write range interface functions with PC.

Who are "we"? And you would prefer to call them where? ;)
Also, tests.

Aug 28 2019, 8:13 AM · Restricted Project, Restricted Project

Jul 17 2019

dvyukov added a comment to D64299: Make ~mutex and ~condition_variable trivial with Bionic pthreads.

Thanks for bringing this up. Indeed this change really hurts TSAN.
I'll look for ways to work around this issue.

I think we could have clang provide an annotation for mutex types that will inject calls to the tsan runtime when a mutex gets created or destroyed.

On a separate note, what kinds of resources leaks are you imagining?

Jul 17 2019, 10:49 PM
dvyukov added a comment to D64299: Make ~mutex and ~condition_variable trivial with Bionic pthreads.

This feels like the right trade-off.

TSan should be fine with a mutex that is never destroyed, but it will not be able to catch lock-after-destroy bugs on such mutex obviously.
@dvyukov

Effectively pthread_mutex_destroy is not trivial under tsan so, yes, there will be a number of negative consequences:

  • no lock-after-destroy races
  • no races between lock/unlock and a subsequent destory
  • no racy use-after-free detection for destroy vs free
  • incorrect stack trace for a mutex that happened to reuse the address later
  • resource leaks for mutexes
  • no reporting of unlock of locked mutex
  • no auto-unlock for destroyed mutexes, which will look like the thread is taking infinite number of locks recursively, which will quickly check-fail in deadlock detector

Why is that not an issue for pthread mutexes with static initialization and no destruction?

Jul 17 2019, 10:46 PM
dvyukov added a comment to D64299: Make ~mutex and ~condition_variable trivial with Bionic pthreads.

This feels like the right trade-off.

TSan should be fine with a mutex that is never destroyed, but it will not be able to catch lock-after-destroy bugs on such mutex obviously.
@dvyukov

Jul 17 2019, 12:19 AM

Jul 4 2019

dvyukov accepted D64092: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.8.
Jul 4 2019, 11:25 AM · Restricted Project, Restricted Project
dvyukov accepted D63946: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.4.

Nice!

Jul 4 2019, 11:24 AM · Restricted Project, Restricted Project
dvyukov accepted D64022: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.5.

Everything that deletes code LGTM :)

Jul 4 2019, 11:24 AM · Restricted Project, Restricted Project

Jul 2 2019

dvyukov accepted D63764: [Sanitizers] Remove obsolete OpenFile from sanitizer_solaris.cc.

Then looks like the right thing to do.
Do you have commit access? Or you want me to submit this?

Jul 2 2019, 1:05 AM · Restricted Project, Restricted Project
dvyukov added a comment to D63764: [Sanitizers] Remove obsolete OpenFile from sanitizer_solaris.cc.

Are you sure it's unused? I see several uses of this function:

Jul 2 2019, 12:48 AM · Restricted Project, Restricted Project

Jul 1 2019

dvyukov accepted D64023: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.6.

Rubber stamp LGTM, if you want a real review please ask somebody else. But if you are sure it's good and covered by tests, submit.

Jul 1 2019, 10:12 PM · Restricted Project, Restricted Project
dvyukov accepted D64050: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.7.

Is there anything else to review at the moment? Want to make sure I did not lost track of things.

Jul 1 2019, 10:07 PM · Restricted Project, Restricted Project
dvyukov accepted D63944: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.3.

Looks good (if it does not break anything :))

Jul 1 2019, 2:21 AM · Restricted Project, Restricted Project
dvyukov accepted D63942: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.2.

Looks good (if it does not break anything :))

Jul 1 2019, 2:19 AM · Restricted Project, Restricted Project
dvyukov added a comment to D60981: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.1.

@dvyukov: I finally have a chance to continue working on this. I hope you are still onboard?

Jul 1 2019, 2:18 AM · Restricted Project, Restricted Project

Jun 24 2019

dvyukov added a comment to D59963: [clang-tidy] Add a module for the Linux kernel..

Re more checks. I guess we can borrow some from the existing checkers:
https://www.kernel.org/doc/html/v4.12/dev-tools/sparse.html
https://bottest.wiki.kernel.org/coccicheck
https://lwn.net/Articles/752408/
https://lwn.net/Articles/691882/

Jun 24 2019, 7:40 AM · Restricted Project, Restricted Project, Restricted Project
dvyukov added a comment to D59963: [clang-tidy] Add a module for the Linux kernel..

I assume you tried to run it on the kernel. Please post the current output somewhere.

Jun 24 2019, 7:37 AM · Restricted Project, Restricted Project, Restricted Project

May 22 2019

dvyukov added a comment to D61708: [TSan] Support `ignore_noninstrumented_modules` on Linux.

If you mean that it will work only for tsan now, I guess it is fine. Other sanitizers can add it when they need it.

May 22 2019, 12:09 AM · Restricted Project, Restricted Project
dvyukov added a comment to D61708: [TSan] Support `ignore_noninstrumented_modules` on Linux.

There is also dlinfo which returns some info about a shared object. I don't know if it may help or not, just pointing out. We need just any mark that the compiler can leave in the shared object and runtime then can detect as easily as possible.

May 22 2019, 12:08 AM · Restricted Project, Restricted Project

May 20 2019

dvyukov added a comment to D61708: [TSan] Support `ignore_noninstrumented_modules` on Linux.

I am still a bit worried by the amount of complex code we have for this. I wonder if there is a simpler way to do this. Have you considered any other alternatives? Could we emit some symbol in the library and then use dlsym on it? Or maybe emit some section and then iterate over section names only?

May 20 2019, 10:21 PM · Restricted Project, Restricted Project

May 8 2019

dvyukov added a comment to D61708: [TSan] Support `ignore_noninstrumented_modules` on Linux.

Evgenii, maybe you can think of some simpler magical way to understand if a module is instrumented or not?

May 8 2019, 10:24 PM · Restricted Project, Restricted Project
dvyukov edited reviewers for D61708: [TSan] Support `ignore_noninstrumented_modules` on Linux, added: vitalybuka, eugenis; removed: samsonov.
May 8 2019, 10:22 PM · Restricted Project, Restricted Project

Apr 23 2019

dvyukov accepted D60981: [TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.1.

JmpBufGarbageCollect uses <= on sp values to detect bufs that are no longer active. But as far as I understand we still will able to do this, right?

Apr 23 2019, 5:12 AM · Restricted Project, Restricted Project

Apr 9 2019

dvyukov added a comment to D60347: [TSan][libdispatch] Replace CFRunLoop with dispatch_semaphore, pt. 1.

As long as the tests pass, it's fine with me :)

Apr 9 2019, 10:16 AM · Restricted Project, Restricted Project

Mar 14 2019

dvyukov accepted D59334: [TSan][libdispatch] Enable linking and running of tests on Linux.

I don't see any problems (because I don't understand cmake), so I am signing off :)

Mar 14 2019, 11:40 PM · Restricted Project, Restricted Project

Mar 7 2019

dvyukov accepted D59113: [TSan] Initialize libdispatch interceptors if necessary.
Mar 7 2019, 10:05 PM · Restricted Project, Restricted Project

Mar 6 2019

dvyukov accepted D59067: [TSan][Linux] Fix libdispatch interception macros compilation errors.
Mar 6 2019, 10:15 PM · Restricted Project, Restricted Project
dvyukov accepted D59037: [Sanitizer] Add 'dispatch' feature to be used in compiler-rt tests.
Mar 6 2019, 10:14 PM · Restricted Project, Restricted Project
dvyukov accepted D59047: [NFC][TSan] Add libdispatch tests for non-Darwin platforms.
Mar 6 2019, 10:13 PM · Restricted Project, Restricted Project
dvyukov accepted D58935: [tsan] Support interception of libdispatch on Linux.

I should have read it better!

Mar 6 2019, 2:23 AM · Restricted Project, Restricted Project

Mar 4 2019

dvyukov added a comment to D58935: [tsan] Support interception of libdispatch on Linux.

I don't mind merging this, but what's the usage/test story here? There are 30+ tests in test/Darwin/gcd-* but they don't run on linux.
Do you intend to do some further development of this support? I just afraid that most users won't be able to use it because it's not enabled, and the ones that will build own compiler will find it broken.

Mar 4 2019, 10:42 PM · Restricted Project, Restricted Project

Feb 25 2019

dvyukov added a comment to D58110: Support fiber API on macOS.

Kuba, please submit this. I can't test/build this.

Feb 25 2019, 12:08 AM · Restricted Project, Restricted Project

Feb 13 2019

dvyukov updated subscribers of D54889: Fiber support for thread sanitizer.

CC @Yi-Hong.Lyu

Feb 13 2019, 8:46 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

I see a similar failure was already reported:
https://reviews.llvm.org/D54889#1394632
There was no fix for it, right? Or did I forgot to squash something else?

Feb 13 2019, 8:45 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.
  • Forwarded message ---------

From: Yi-Hong Lyu via Phabricator <reviews@reviews.llvm.org>
Date: Wed, Feb 13, 2019 at 5:33 PM
Subject: [Diffusion] rL353817: tsan: add fiber support

Feb 13 2019, 8:42 AM · Restricted Project, Restricted Project
dvyukov committed rG76e961207bd1: tsan: add fiber support (authored by dvyukov).
tsan: add fiber support
Feb 13 2019, 5:21 AM
dvyukov closed D58171: Fix thread sanitizer on aarch64.

This is submitted as part of 353947

Feb 13 2019, 5:21 AM · Restricted Project, Restricted Project
dvyukov committed rCRT353947: .
Feb 13 2019, 5:21 AM
dvyukov committed rL353947: .
Feb 13 2019, 5:21 AM
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Resubmitted in 353947 with 2 fixes squashed.

Feb 13 2019, 5:21 AM · Restricted Project, Restricted Project
dvyukov accepted D58171: Fix thread sanitizer on aarch64.

Looks good to me.

Feb 13 2019, 4:36 AM · Restricted Project, Restricted Project

Feb 12 2019

dvyukov added a comment to D58110: Support fiber API on macOS.

Kuba, please take a look. This mostly touches Mac-specific files. I can't test this.

Feb 12 2019, 2:39 AM · Restricted Project, Restricted Project
dvyukov committed rG19e41fb0ca4d: tsan: update check_analyze.sh (authored by dvyukov).
tsan: update check_analyze.sh
Feb 12 2019, 2:18 AM
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

FTR updated check_analyze.sh in http://llvm.org/viewvc/llvm-project?view=revision&revision=353820

Feb 12 2019, 2:18 AM · Restricted Project, Restricted Project
dvyukov committed rCRT353820: tsan: update check_analyze.sh.
tsan: update check_analyze.sh
Feb 12 2019, 2:18 AM
dvyukov committed rL353820: tsan: update check_analyze.sh.
tsan: update check_analyze.sh
Feb 12 2019, 2:18 AM
dvyukov closed D54889: Fiber support for thread sanitizer.

Committed in:
http://llvm.org/viewvc/llvm-project?view=revision&revision=353817

Feb 12 2019, 2:14 AM · Restricted Project, Restricted Project
dvyukov committed rG6e7089ad4036: tsan: add fiber support (authored by dvyukov).
tsan: add fiber support
Feb 12 2019, 2:12 AM
dvyukov committed rCRT353817: tsan: add fiber support.
tsan: add fiber support
Feb 12 2019, 2:12 AM
dvyukov accepted D54889: Fiber support for thread sanitizer.
Feb 12 2019, 2:12 AM · Restricted Project, Restricted Project
dvyukov committed rL353817: tsan: add fiber support.
tsan: add fiber support
Feb 12 2019, 2:12 AM
dvyukov added inline comments to D58108: [sanitizer]: fix warnings reported by SVACE static analyzer..
Feb 12 2019, 1:25 AM · Restricted Project, Restricted Project
dvyukov committed rGca524b19c152: tsan: Introduce in_symbolizer() function for Thread sanitizer (authored by dvyukov).
tsan: Introduce in_symbolizer() function for Thread sanitizer
Feb 12 2019, 12:12 AM
dvyukov committed rCRT353805: tsan: Introduce in_symbolizer() function for Thread sanitizer.
tsan: Introduce in_symbolizer() function for Thread sanitizer
Feb 12 2019, 12:11 AM
dvyukov committed rL353805: tsan: Introduce in_symbolizer() function for Thread sanitizer.
tsan: Introduce in_symbolizer() function for Thread sanitizer
Feb 12 2019, 12:11 AM
dvyukov closed D58104: Introduce in_symbolizer() function for Thread sanitizer.

Submitted in 353805.

Feb 12 2019, 12:10 AM · Restricted Project, Restricted Project
dvyukov accepted D58104: Introduce in_symbolizer() function for Thread sanitizer.

Perfect! Thanks!
Testing and submitting.

Feb 12 2019, 12:08 AM · Restricted Project, Restricted Project

Feb 11 2019

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

However, for thread initialization we rely on the fact that pthread's thread entry function (start_thread) calls _setjmp which we intercept. If start_thread does not call _setjmp then we risk to hit NULL cur_thread in secondary threads. I think we need to add cur_thread_init also to:

  1. SCOPED_INTERCEPTOR_RAW (this will ensure that if start_thread calls any intercepted libc function, we will init at that point)

There is a lot if interceptors that do

if (cur_thread()->in_symbolizer)

before SCOPED_INTERCEPTOR_RAW. What to do with them?

Feb 11 2019, 6:47 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

The change is now a very good shape.

Feb 11 2019, 4:05 AM · Restricted Project, Restricted Project
dvyukov added a comment to D57876: Implement pthread_exit() interceptor for Thread sanitizer.

I've seen some fixes has landed over the weekend. Is this fixed now? Or some breakages still remain?

macOS is fixed.
Test on ppc64 is disabled — pthread_exit does not work there without any interceptors.

Feb 11 2019, 2:02 AM · Restricted Project, Restricted Project
dvyukov added a comment to D57876: Implement pthread_exit() interceptor for Thread sanitizer.

I've seen some fixes has landed over the weekend. Is this fixed now? Or some breakages still remain?

Feb 11 2019, 1:33 AM · Restricted Project, Restricted Project
dvyukov added a comment to rL353385: tsan: Implement pthread_exit() interceptor for Thread sanitizer.

Hi Yi-Hong,
Let's move the discussion to https://reviews.llvm.org/D57876 because there is already some.

Feb 11 2019, 1:32 AM

Feb 8 2019

dvyukov added a comment to D57876: Implement pthread_exit() interceptor for Thread sanitizer.

One thing that I noticed is that pthread_exit is a noreturn function and SCOPED_TSAN_INTERCEPTOR creates a local object with destructor. At the very least this leads to confusing code where readers assumption is that the destructor will run, but it will not.
Perhaps we should try to remove the SCOPED_TSAN_INTERCEPTOR entirely as the CHECK that we want to add here does not need it.

Feb 8 2019, 12:22 AM · Restricted Project, Restricted Project
dvyukov added a comment to D57876: Implement pthread_exit() interceptor for Thread sanitizer.
  • Forwarded message ---------

From: Alex L
Date: Fri, Feb 8, 2019 at 1:17 AM
Subject: Re: [compiler-rt] r353385 - tsan: Implement pthread_exit() interceptor for Thread sanitizer

Feb 8 2019, 12:13 AM · Restricted Project, Restricted Project

Feb 7 2019

dvyukov added a comment to D54889: Fiber support for thread sanitizer.

To clarify the graph: it's difference in execution time in percents as compared to the current HEAD. I.e. -4 means that fibers are 4% slower than the current HEAD.
1w means mop.cc benchmark with 1-byte write accesses; 4r - 4-byte read accesses. ee is func_entry_exit.cc benchmark.

Feb 7 2019, 9:37 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Did another round of benchmarking of this change on the current HEAD using these 2 benchmarks:
https://github.com/llvm-mirror/compiler-rt/blob/master/lib/tsan/benchmarks/mop.cc
https://github.com/llvm-mirror/compiler-rt/blob/master/lib/tsan/benchmarks/func_entry_exit.cc

Feb 7 2019, 9:33 AM · Restricted Project, Restricted Project
dvyukov added a comment to D54889: Fiber support for thread sanitizer.

Current code runs in 7.16s
This change -- 6.23s
This change + cur_thread_fast returning cur_thread_placeholder -- 7.01s
I also tried this change + FuncEntry using cur_thread_fast -- 6.20s

But if I do:

INLINE ThreadState *cur_thread_fast() {
  ThreadState* thr;
  __asm__("": "=a"(thr): "a"(&cur_thread_placeholder[0]));
  return thr;
}

(which is a dirty trick to force compiler to cache address of the tls object in a register) then the program runs 5.94s -- faster than any other options as it takes advantage of both no indirection and faster instructions.

Feb 7 2019, 6:09 AM · Restricted Project, Restricted Project
dvyukov committed rGbdfba86047cd: tsan: add more benchmarks (authored by dvyukov).
tsan: add more benchmarks
Feb 7 2019, 6:05 AM