[Sanitizer][Darwin] Factor out code for GCD worker registration

This is a NFC change to factor out GCD worker thread registration via
the pthread introspection hook.

In a follow-up change we also w

[Sanitizer][Darwin] Factor out code for GCD worker registration

This is a NFC change to factor out GCD worker thread registration via
the pthread introspection hook.

In a follow-up change we also want to register GCD workers for ASan to
make sure threads are registered before we attempt to print reports on
them.

rdar://93276353

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

show more ...

[Sanitizers][Darwin] Replace SANITIZER_MAC with SANITIZER_APPLE in source files

This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816)

Performed a

[Sanitizers][Darwin] Replace SANITIZER_MAC with SANITIZER_APPLE in source files

This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816)

Performed a global search/replace as in title against LLVM sources

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

show more ...

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vecto

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vector clocks (512b)
- fast vectorized vector clock operations
- unlimited number of alive threads/goroutimes

Depends on D112602.

Reviewed By: melver

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

show more ...

Revert "tsan: new runtime (v3)"

This reverts commit 5a33e412815b8847610425a2a3b86d2c7c313b71 becuase it
breaks LLDB.

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/39208/

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vecto

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vector clocks (512b)
- fast vectorized vector clock operations
- unlimited number of alive threads/goroutimes

Depends on D112602.

Reviewed By: melver

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

show more ...

Revert "tsan: new runtime (v3)"

This reverts commit 66d4ce7e26a5ab00f7e4946b6e1bac8f805010fa.

Chromium tests started failing:
https://bugs.chromium.org/p/chromium/issues/detail?id=1275581

[TSan][Darwin] Avoid crashes due to interpreting non-zero shadow content as a pointer

We would like to use TLS to store the ThreadState object (or at least a
reference ot it), but on Darwin accessin

[TSan][Darwin] Avoid crashes due to interpreting non-zero shadow content as a pointer

We would like to use TLS to store the ThreadState object (or at least a
reference ot it), but on Darwin accessing TLS via __thread or manually
by using pthread_key_* is problematic, because there are several places
where interceptors are called when TLS is not accessible (early process
startup, thread cleanup, ...).

Previously, we used a "poor man's TLS" implementation, where we use the
shadow memory of the pointer returned by pthread_self() to store a
pointer to the ThreadState object.

The problem with that was that certain operations can populate shadow
bytes unbeknownst to TSan, and we later interpret these non-zero bytes
as the pointer to our ThreadState object and crash on when dereferencing
the pointer.

This patch changes the storage location of our reference to the
ThreadState object to "real" TLS. We make this work by artificially
keeping this reference alive in the pthread_key destructor by resetting
the key value with pthread_setspecific().

This change also fixes the issue were the ThreadState object is
re-allocated after DestroyThreadState() because intercepted functions
can still get called on the terminating thread after the
THREAD_TERMINATE event.

Radar-Id: rdar://problem/72010355

Reviewed By: dvyukov

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

show more ...

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vecto

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vector clocks (512b)
- fast vectorized vector clock operations
- unlimited number of alive threads/goroutimes

Depends on D112602.

Reviewed By: melver

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

show more ...

Revert "tsan: new runtime (v3)"

This reverts commit ebd47b0fb78fa11758da6ffcd3e6b415cbb8fa28.
This was causing unexpected behavior in programs.

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vecto

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vector clocks (512b)
- fast vectorized vector clock operations
- unlimited number of alive threads/goroutimes

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

show more ...

Revert "tsan: new runtime (v3)"

Summary:
This reverts commit 1784fe0532a69ead17793bced060a9bf9d232027.

Broke some bots:
https://lab.llvm.org/buildbot#builders/57/builds/12365
http://green.lab.llvm.

Revert "tsan: new runtime (v3)"

Summary:
This reverts commit 1784fe0532a69ead17793bced060a9bf9d232027.

Broke some bots:
https://lab.llvm.org/buildbot#builders/57/builds/12365
http://green.lab.llvm.org/green/job/clang-stage1-RA/25658/

Reviewers: vitalybuka, melver

Subscribers:

show more ...

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vecto

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vector clocks (512b)
- fast vectorized vector clock operations
- unlimited number of alive threads/goroutimes

Depends on D112602.

Reviewed By: melver

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

show more ...

Revert "tsan: new runtime (v3)"

Summary:
This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b.
There is a number of bot failures:
http://45.33.8.238/mac/38755/step_4.txt
https://green.lab.ll

Revert "tsan: new runtime (v3)"

Summary:
This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b.
There is a number of bot failures:
http://45.33.8.238/mac/38755/step_4.txt
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c

Reviewers: vitalybuka, melver

Subscribers:

show more ...

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vecto

tsan: new runtime (v3)

This change switches tsan to the new runtime which features:
- 2x smaller shadow memory (2x of app memory)
- faster fully vectorized race detection
- small fixed-size vector clocks (512b)
- fast vectorized vector clock operations
- unlimited number of alive threads/goroutimes

Depends on D112602.

Reviewed By: melver

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

show more ...

[compiler-rt] update detect_write_exec option for apple devices.

Reviewed By: yln, vitalybuka

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

tsan: improve detection of stack/tls races

Print meaningful stack frames for stack/tls races
(instead of PC 1/2 that don't symbolize).

Imitate stack/tls writes after we create and initialize
the ne

tsan: improve detection of stack/tls races

Print meaningful stack frames for stack/tls races
(instead of PC 1/2 that don't symbolize).

Imitate stack/tls writes after we create and initialize
the new thread, otherwise the races are not detected.

This is re-submit of the following reverted commits,
but without tests as they failed on a number of OSes/arches:
"tsan: fix and test detection of TLS races"
"tsan: fix tls_race3 test on darwin"
"tsan: print a meaningful frame for stack races"

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

show more ...

Revert "tsan: fix tls_race3 test on darwin"

This reverts commit ade5023c54cffcbefe0557b5473d55b06e40809b.

Reverting this commit as it is dependent on a test breaking the PPC BE bots.

[NFC][sanitizer] Return StackDepotStats by value

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

[NFC][sanitizer] Clang-format some code

tsan: fix tls_race3 test on darwin

Darwin also needs to use __tsan_tls_initialization
to pass the test.

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

tsan: write uptime in mem profile

Write uptime in real time seconds for every mem profile record.
Uptime is useful to make more sense out of the profile,
compare random lines, etc.

Depends on D1101

tsan: write uptime in mem profile

Write uptime in real time seconds for every mem profile record.
Uptime is useful to make more sense out of the profile,
compare random lines, etc.

Depends on D110153.

Reviewed By: melver, vitalybuka

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

show more ...

tsan: make mem profile data more consistent

We currently query number of threads before reading /proc/self/smaps.
But reading /proc/self/smaps can take lots of time for huge processes
and it's retri

tsan: make mem profile data more consistent

We currently query number of threads before reading /proc/self/smaps.
But reading /proc/self/smaps can take lots of time for huge processes
and it's retries several times with different buffer sizes.
Overall it can take tens of seconds. This can make number of threads
significantly inconsistent with the rest of the stats.
So query it after reading /proc/self/smaps.

Depends on D110149.

Reviewed By: melver, vitalybuka

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

show more ...

tsan: fix build breakage due to AppMemBeg

AppMemBeg was renamed to LoAppMemBeg in 3830c93478
("tsan: rename kAppMemBeg to kLoAppMemBeg").
Rename remaining uses of the old name in tsan_platform_mac.c

tsan: fix build breakage due to AppMemBeg

AppMemBeg was renamed to LoAppMemBeg in 3830c93478
("tsan: rename kAppMemBeg to kLoAppMemBeg").
Rename remaining uses of the old name in tsan_platform_mac.cpp.

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

show more ...

tsan: remove dependencies on HAS_48_BIT_ADDRESS_SPACE and Mapping

Remove direct uses of Mapping in preperation for removing Mapping type
(which we already don't have for all platforms).
Remove depen

tsan: remove dependencies on HAS_48_BIT_ADDRESS_SPACE and Mapping

Remove direct uses of Mapping in preperation for removing Mapping type
(which we already don't have for all platforms).
Remove dependence on HAS_48_BIT_ADDRESS_SPACE in preparation for removing it.
As far as I see for Apple/Mac platforms !HAS_48_BIT_ADDRESS_SPACE
simply means SANITIZER_IOS.

Depends on D107741.

Reviewed By: melver

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

show more ...

tsan: introduce Tid and StackID typedefs

Currently we inconsistently use u32 and int for thread ids,
there are also "unique tid" and "os tid" and just lots of other
things identified by integers.
Ad

tsan: introduce Tid and StackID typedefs

Currently we inconsistently use u32 and int for thread ids,
there are also "unique tid" and "os tid" and just lots of other
things identified by integers.
Additionally new tsan runtime will introduce yet another
thread identifier that is very different from current tids.
Similarly for stack IDs, it's easy to confuse u32 with other
integer identifiers. And when a function accepts u32 or a struct
contains u32 field, it's not always clear what it is.

Add Tid and StackID typedefs to make it clear what is what.

Reviewed By: melver

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

show more ...