[Lldb-commits] [libunwind] [compiler-rt] [mlir] [llvm] [lld] [flang] [lldb] [libcxx] [libcxxabi] [clang] [libc] [clang-tools-extra] [asan] Install `pthread_atfork` (PR #75290)

2023-12-15 Thread Rainer Orth via lldb-commits 

rorth wrote:

Since this patch, all asan tests loop on Solaris.  This had been hidden for a 
bit by an unrelated extended build breakage on the bots, but now every `ninja 
check-all` on the Solaris/amd64 bot times out.  I could trace this to this 
patch.

E.g. when running 
`projects/compiler-rt/test/asan/I386SunOSConfig/TestCases/Output/alloca_big_alignment.cpp.tmp`,
 I get the expected output
```
=
==3==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 
0xfeffd88a at pc 0x0812907d bp 0xfeffd7f4 sp 0xfeffd7ec
WRITE of size 1 at 0xfeffd88a thread T0
```
and afterwards the test loops.  `truss` shows an unending series of
```
22210:  yield() = 0
22210:  yield() = 0
22210:  yield() = 0
```
and `pstack` gives
```
22213:  /var/llvm/local-amd64-release-stage2-A-flang-492214/tools/clang/stage2
 fdfbebc5 yield(0x8139158, 0x8109558, 0x818a580, 0x0, 0x5dd, 0x8139158) + 15
 0810cd32 __sanitizer::FutexWait(__sanitizer::atomic_uint32_t*, unsigned int) 
(0xfe00a000, 0xfdebdd56, 0x805ad7c, 0xfdfa0107, 0xfeffc68c, 0x5) + 12
 080f4952 __asan::InstallAtForkHandler()::$_0::__invoke() (0xfde26fc0, 0x7, 
0xfe010200, 0xfe010140, 0x7, 0x5) + 12
 fdfa49c8 forkx(0x0, 0xfe5ad000, 0x89f, 0xfdfa4b8c) + c8
 fdfa4b9d fork (0x8139158, 0x811563e, 0xfeffc720, 0xfd6007a0, 0x4, 
0x8139158) + 1d
 0810ccd2 __sanitizer::internal_fork() () + 12
```
This seems no wonder given that `sanitizer_common/sanitizer_solaris.cpp` has
```
void FutexWait(atomic_uint32_t *p, u32 cmp) {
  // FIXME: implement actual blocking.
  sched_yield();
}
```
`sanitizer_mac.cpp` is the same, btw., and even `sanitizer_linux.cpp` has
```
#  if !SANITIZER_SOLARIS
void FutexWait(atomic_uint32_t *p, u32 cmp) {
#if SANITIZER_FREEBSD
  _umtx_op(p, UMTX_OP_WAIT_UINT, cmp, 0, 0);
#elif SANITIZER_NETBSD
  sched_yield(); /* No userspace futex-like synchronization */
#else
  internal_syscall(SYSCALL(futex), (uptr)p, FUTEX_WAIT_PRIVATE, cmp, 0, 0, 0);
#endif
}
```
so even NetBSD would be affected.

https://github.com/llvm/llvm-project/pull/75290
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libcxx] [libc] [clang] [lldb] [libcxxabi] [libunwind] [lld] [compiler-rt] [llvm] [clang-tools-extra] [flang] [mlir] [asan] Install `pthread_atfork` (PR #75290)

2023-12-19 Thread Rainer Orth via lldb-commits 

rorth wrote:

It took me a bit to notice this snippet in `sanitizer_solaris.cpp`:
```
DECLARE__REAL_AND_INTERNAL(int, fork, void) {
  // TODO(glider): this may call user's pthread_atfork() handlers which is bad.
  return _REAL(fork)();
}
```
which didn't show up in searches for `internal_fork`.

>From what I could learn from `libc` disassembly and the OpenSolaris sources, 
>the only way to avoid the handlers on Solaris is to invoke the syscall 
>directly.  This is highly unportable, however: syscalls are an implemention 
>detail that can (and **does**) change.  There's reasonable hope that this 
>won't happen for the remaining livetime of Solaris 11.4, though.

I'll give such a patch a try...

https://github.com/llvm/llvm-project/pull/75290
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [compiler-rt] [clang-tools-extra] [mlir] [libunwind] [libcxxabi] [llvm] [lldb] [libcxx] [flang] [lld] [libc] [asan] Install `pthread_atfork` (PR #75290)

2023-12-21 Thread Rainer Orth via lldb-commits 

rorth wrote:

> I'll give such a patch a try...

That would be something like
```
int internal_fork(void) {
  // Call syscall directly to avoid pthread_atfork handler processing.
  //
  // This is highly unportable on Solaris since syscalls are an implementation
  // detail subject to change.
  return syscall(SYS_forksys, 0, 0);
}
```
Unfortunately, this fails miserably: at least every asan test that invokes the 
`llvm-symbolizer` fails like
```
==4030==Launching Symbolizer process: /usr/bin/llvm-symbolizer --demangle 
--inlines --default-arch=i386 
==4031==Waiting on the process failed (errno 10).
==4031==WARNING: external symbolizer didn't start up correctly!
```
>From all I could learn from the OpenSolaris `libc` code 
>(`lib/libc/port/threads/scalls.c` (`forkx`), it seems that there happens so 
>much processing on `libc`-internal data structures that cannot simply be 
>skipped that there's no reasonable chance to run `fork` without the handlers.  
>Expecting to be able to seems to be hack that may work on some platforms, but 
>not on others.

https://github.com/llvm/llvm-project/pull/75290
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r367865 - [lldb][clang] Reflect LangStandard.h move to clang/Basic

2019-10-04 Thread Rainer Orth via lldb-commits 
Author: ro
Date: Mon Aug  5 07:00:43 2019
New Revision: 367865

URL: http://llvm.org/viewvc/llvm-project?rev=367865&view=rev
Log:
[lldb][clang] Reflect LangStandard.h move to clang/Basic

D65562  moves LangStandard.h from 
clang/Frontend to clang/Basic.  This patch
adjusts the single file in lldb that uses it to match.

Tested on x86_64-pc-linux-gnu.

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

Modified:
lldb/trunk/source/Symbol/ClangASTContext.cpp

Modified: lldb/trunk/source/Symbol/ClangASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/ClangASTContext.cpp?rev=367865&r1=367864&r2=367865&view=diff
==
--- lldb/trunk/source/Symbol/ClangASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/ClangASTContext.cpp Mon Aug  5 07:00:43 2019
@@ -47,11 +47,11 @@
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/FileManager.h"
 #include "clang/Basic/FileSystemOptions.h"
+#include "clang/Basic/LangStandard.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/Basic/TargetOptions.h"
 #include "clang/Frontend/FrontendOptions.h"
-#include "clang/Frontend/LangStandard.h"
 #include "clang/Sema/Sema.h"
 
 #ifdef LLDB_DEFINED_NDEBUG_FOR_CLANG
@@ -111,10 +111,10 @@ namespace {
 static inline bool
 ClangASTContextSupportsLanguage(lldb::LanguageType language) {
   return language == eLanguageTypeUnknown || // Clang is the default type 
system
- Language::LanguageIsC(language) ||
- Language::LanguageIsCPlusPlus(language) ||
- Language::LanguageIsObjC(language) ||
- Language::LanguageIsPascal(language) ||
+ lldb_private::Language::LanguageIsC(language) ||
+ lldb_private::Language::LanguageIsCPlusPlus(language) ||
+ lldb_private::Language::LanguageIsObjC(language) ||
+ lldb_private::Language::LanguageIsPascal(language) ||
  // Use Clang for Rust until there is a proper language plugin for it
  language == eLanguageTypeRust ||
  language == eLanguageTypeExtRenderScript ||
@@ -571,7 +571,7 @@ static void ParseLangArgs(LangOptions &O
   // Set some properties which depend solely on the input kind; it would be
   // nice to move these to the language standard, and have the driver resolve
   // the input kind + language standard.
-  if (IK.getLanguage() == InputKind::Asm) {
+  if (IK.getLanguage() == clang::Language::Asm) {
 Opts.AsmPreprocessor = 1;
   } else if (IK.isObjectiveC()) {
 Opts.ObjC = 1;
@@ -582,26 +582,26 @@ static void ParseLangArgs(LangOptions &O
   if (LangStd == LangStandard::lang_unspecified) {
 // Based on the base language, pick one.
 switch (IK.getLanguage()) {
-case InputKind::Unknown:
-case InputKind::LLVM_IR:
-case InputKind::RenderScript:
+case clang::Language::Unknown:
+case clang::Language::LLVM_IR:
+case clang::Language::RenderScript:
   llvm_unreachable("Invalid input kind!");
-case InputKind::OpenCL:
+case clang::Language::OpenCL:
   LangStd = LangStandard::lang_opencl10;
   break;
-case InputKind::CUDA:
+case clang::Language::CUDA:
   LangStd = LangStandard::lang_cuda;
   break;
-case InputKind::Asm:
-case InputKind::C:
-case InputKind::ObjC:
+case clang::Language::Asm:
+case clang::Language::C:
+case clang::Language::ObjC:
   LangStd = LangStandard::lang_gnu99;
   break;
-case InputKind::CXX:
-case InputKind::ObjCXX:
+case clang::Language::CXX:
+case clang::Language::ObjCXX:
   LangStd = LangStandard::lang_gnucxx98;
   break;
-case InputKind::HIP:
+case clang::Language::HIP:
   LangStd = LangStandard::lang_hip;
   break;
 }
@@ -901,8 +901,9 @@ IdentifierTable *ClangASTContext::getIde
 LangOptions *ClangASTContext::getLanguageOptions() {
   if (m_language_options_up == nullptr) {
 m_language_options_up.reset(new LangOptions());
-ParseLangArgs(*m_language_options_up, InputKind::ObjCXX, 
GetTargetTriple());
-//InitializeLangOptions(*m_language_options_up, InputKind::ObjCXX);
+ParseLangArgs(*m_language_options_up, clang::Language::ObjCXX,
+  GetTargetTriple());
+//InitializeLangOptions(*m_language_options_up, Language::ObjCXX);
   }
   return m_language_options_up.get();
 }


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