[DynInst_API:] [dyninst/dyninst] 0a996a: Compile parseAPI with -pthread to fix Clang thread...


Date: Thu, 09 Jul 2026 22:36:59 -0700
From: bbiiggppiigg <noreply@xxxxxxxxxx>
Subject: [DynInst_API:] [dyninst/dyninst] 0a996a: Compile parseAPI with -pthread to fix Clang thread...
  Branch: refs/heads/master
  Home:   https://github.com/dyninst/dyninst
  Commit: 0a996ac60bb6e137d298ae76d6392a1e63273a64
      https://github.com/dyninst/dyninst/commit/0a996ac60bb6e137d298ae76d6392a1e63273a64
  Author: bbiiggppiigg <bbiiggppiigg@xxxxxxxxx>
  Date:   2026-07-10 (Fri, 10 Jul 2026)

  Changed paths:
    M cmake/tpls/DyninstThreads.cmake
    M parseAPI/CMakeLists.txt

  Log Message:
  -----------
  Compile parseAPI with -pthread to fix Clang thread-safety (#2311)

* Compile parseAPI with -pthread to fix Clang thread-safety

Dyninst's bundled Sawyer/ROSE only compiles its pool allocator and
shared-pointer reference counting as thread-safe when _REENTRANT is
defined (dataflowAPI/rose/util/Sawyer.h). GCC's -fopenmp defines
_REENTRANT implicitly, but Clang's -fopenmp=libomp does not, so Clang
builds ran the OpenMP-parallel parser with no-op allocator locks. This
corrupted the pool free list and SValue reference counts, causing
assertion failures and segfaults during parallel jump-table symbolic
evaluation (only reproducible with >1 OpenMP thread).

Rather than defining the deprecated _REENTRANT macro directly, set
THREADS_PREFER_PTHREAD_FLAG and link parseAPI against Threads::Threads.
On GCC/Clang, -pthread defines _REENTRANT as a documented side effect
(see feature_test_macros(7)), so this is the standard, compiler-
independent way to compile threaded code. All Sawyer/ROSE sources
compile into the single parseAPI target and none of the affected types
are exposed in public headers, so scoping the flag to parseAPI keeps
the shared-object layout consistent (no ODR mismatch) without touching
the vendored Sawyer header.

Threads::Threads is linked unconditionally (not gated on USE_OpenMP) so
the ROSE classes remain thread-safe even in non-OpenMP builds where the
application itself drives them from multiple threads.

This is an alternative to the global add_compile_definitions(_REENTRANT)
approach in PR #2310, offered for reviewer comparison.

Co-Authored-By: Claude Opus 4.8 <noreply@xxxxxxxxxxxxx>



To unsubscribe from these emails, change your notification settings at https://github.com/dyninst/dyninst/settings/notifications
[← Prev in Thread] Current Thread [Next in Thread→]
  • [DynInst_API:] [dyninst/dyninst] 0a996a: Compile parseAPI with -pthread to fix Clang thread..., bbiiggppiigg <=