[PATCH] D141385: [sanitizer_common] Don't intercept __tls_get_addr on Solaris

[Rainer Orth via Phabricator via llvm-commits]

ro created this revision.
ro added a reviewer: vitalybuka.
ro added a project: Sanitizers.
Herald added subscribers: Enna1, pengfei, fedor.sergeev, krytarowski, arichardson, emaste, jyknight.
Herald added a project: All.
ro requested review of this revision.
Herald added a subscriber: Sanitizers.

When building/testing ASan inside the GCC tree on Solaris while using GNU `ld` instead of Solaris `ld`, a large number of tests SEGVs on both sparc and x86 like this:

  Thread 2 received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 1 (LWP 1)]
  0xfe014cfc in __sanitizer::atomic_load<__sanitizer::atomic_uintptr_t> (a=0xfc602a58, mo=__sanitizer::memory_order_acquire) at sanitizer_common/sanitizer_atomic_clang_x86.h:46
  46	      v = a->val_dont_use;
  1: x/i $pc
  => 0xfe014cfc <_ZN11__sanitizer11atomic_loadINS_16atomic_uintptr_tEEENT_4TypeEPVKS2_NS_12memory_orderE+62>:	mov    (%eax),%eax
  (gdb) bt
  #0  0xfe014cfc in __sanitizer::atomic_load<__sanitizer::atomic_uintptr_t> (a=0xfc602a58, mo=__sanitizer::memory_order_acquire) at sanitizer_common/sanitizer_atomic_clang_x86.h:46
  #1  0xfe0bd1d7 in __sanitizer::DTLS_NextBlock (cur=0xfc602a58) at sanitizer_common/sanitizer_tls_get_addr.cpp:53
  #2  0xfe0bd319 in __sanitizer::DTLS_Find (id=1) at sanitizer_common/sanitizer_tls_get_addr.cpp:77
  #3  0xfe0bd466 in __sanitizer::DTLS_on_tls_get_addr (arg_void=0xfeffd068, res=0xfe602a18, static_tls_begin=0, static_tls_end=0) at sanitizer_common/sanitizer_tls_get_addr.cpp:116
  #4  0xfe063f81 in __interceptor___tls_get_addr (arg=0xfeffd068) at sanitizer_common/sanitizer_common_interceptors.inc:5501
  #5  0xfe0a3054 in __sanitizer::CollectStaticTlsBlocks (info=0xfeffd108, size=40, data=0xfeffd16c) at sanitizer_common/sanitizer_linux_libcdep.cpp:366
  #6  0xfe6ba9fa in dl_iterate_phdr () from /usr/lib/ld.so.1
  #7  0xfe0a3132 in __sanitizer::GetStaticTlsBoundary (addr=0xfe608020, size=0xfeffd244, align=0xfeffd1b0) at sanitizer_common/sanitizer_linux_libcdep.cpp:382
  #8  0xfe0a33f7 in __sanitizer::GetTls (addr=0xfe608020, size=0xfeffd244) at sanitizer_common/sanitizer_linux_libcdep.cpp:482
  #9  0xfe0a34b1 in __sanitizer::GetThreadStackAndTls (main=true, stk_addr=0xfe608010, stk_size=0xfeffd240, tls_addr=0xfe608020, tls_size=0xfeffd244) at sanitizer_common/sanitizer_linux_libcdep.cpp:565

The address being accessed is unmapped.  However, even when the tests `PASS` with Solaris `ld`, `ASAN_OPTIONS=verbosity=2` shows

  ==6582==__tls_get_addr: Can't guess glibc version

Given that that the code is stricly `glibc`-specific according to `sanitizer_tls_get_addr.h`, there seems little point in using the interceptor on non-`glibc` targets.

That's what this patch does.  Tested on `i386-pc-solaris2.11` and `sparc-sun-solaris2.11` inside the GCC tree.

Given all this, it seems highly dubious to use the interceptor on FreeBSD and NetBSD as is currently done.  I'll leave changing this to someone who can actually test such a patch, though.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D141385

Files:
  compiler-rt/lib/sanitizer_common/sanitizer_platform_interceptors.h


Index: compiler-rt/lib/sanitizer_common/sanitizer_platform_interceptors.h
===================================================================
--- compiler-rt/lib/sanitizer_common/sanitizer_platform_interceptors.h
+++ compiler-rt/lib/sanitizer_common/sanitizer_platform_interceptors.h
@@ -405,7 +405,7 @@
   (SI_FREEBSD || SI_NETBSD || SI_GLIBC || SI_SOLARIS)
 
 #define SANITIZER_INTERCEPT_TLS_GET_ADDR \
-  (SI_FREEBSD || SI_NETBSD || SI_LINUX_NOT_ANDROID || SI_SOLARIS)
+  (SI_FREEBSD || SI_NETBSD || SI_LINUX_NOT_ANDROID)
 
 #define SANITIZER_INTERCEPT_LISTXATTR SI_LINUX
 #define SANITIZER_INTERCEPT_GETXATTR SI_LINUX


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D141385.487791.patch
Type: text/x-patch
Size: 622 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230110/66f88578/attachment.bin>