feat(otel_thread_ctx): thread-level ctx publication (#1791)

# What does this PR do?

This PR implements a first version of publishing side of the [OTel proposal on thread-level context sharing](https://github.com/open-telemetry/opentelemetry-specification/pull/4947/changes).

The changes are two-folds:

1. Add a C shim for accessing the correct thread-local variable that holds the thread context. Indeed the spec mandates the use of the TLSDESC dialect, but this isn't possible in Rust, which uses the classical TLS dialect (`gnu` instead of `gnu2`) by default. This is not possible to configure on stable Rust. See additional notes below for more details.
2. Add a new `otel_thread_ctx` module, similar to the `otel_process_ctx` one, which provides an abstraction over the thread-level context and handle attach/detach/modify.

The part of the spec around the interned string table, hooking it up in the process-level ctx and tracer metadata is left for future work.

# Motivation

See the corresponding OTEP linked above for more details on the motivation.

# Additional Notes

TLSDESC is chosen in the spec for performance reasons. I initially found a bit sad that we have to call to a C function from `libdatadog` to retrieve the TLS address, which incurs an additional cost. I researched potential alternatives:

- force Rust to use the TLSDESC dialect. This is just not possible/supported.
- cache the address (which is stable per thread). But this must be put in...drumroll... another thread-local variable, since it's well, thread-local, so back to square one. One possibility would be to use a `cached_addr` thread-local and force the access to use the `initial-exec` model, which is very fast (the price to pay is that libdatadog coulnd't be `dlopen` at runtime, but I'm not sure there's any usage for that). We would trade a function call for an offset and loads, which I expect to be faster. But this requires [nightly Rust](https://doc.rust-lang.org/unstable-book/compiler-flags/tls-model.html), unfortunately, and would apply to the entirety of `libdatadog`.
- inline-asm: the access sequence for TLSDESC is really simple (it's a few LLVM IR instructions, calling a function obtained from the global offset table). I looked into inline LLVM assembly for Rust, but it's not supported and is anon-goal (LLVM is almost considered as an implementation detail, as rust-gcc could one day become a viable alternative, for example). Native ASM is just too much hassle to pay off.

All in all, I think there's no simple, reasonable, portable and maintainable alternative to the C shim for now. It is worth noting that calling to the C shim is likely to be still faster than the default TLS model chosen by Rust in a dynamic library (the latter requires a function call to `__get_tls_addr` anyway, but that function is more involved). I wonder if some aggressive cross-language late LTO could inline the C shim.

# How to test the change?

There are a bunch of tests in this PR. Ideally we will later test this against other thread-level ctx readers implementations once we hook this work in the FFI; this is left for a follow-up.

Co-authored-by: yann.hamdaoui <yann.hamdaoui@datadoghq.com>

Author: yannham

Cargo.lock

@@ -1,4 +1,4 @@
-// Copyright 2021-Present Datadog, Inc. https://www.datadoghq.com/
+// Copyright 2026-Present Datadog, Inc. https://www.datadoghq.com/
 // SPDX-License-Identifier: Apache-2.0
 
 //! Implementation of the publisher part of the [OTEL process
@@ -8,7 +8,8 @@
 //!
 //! Process context sharing implies concurrently writing to a memory area that another process
 //! might be actively reading. However, reading isn't done as direct memory accesses but goes
-//! through the OS, so the Rust definition of race conditions doesn't really apply.
+//! through the OS, so the Rust definition of race conditions doesn't really apply. We also use
+//! atomics and fences, see MappingHeader's documentation.
 
 #[cfg(target_os = "linux")]
 #[cfg(target_has_atomic = "64")]

libdd-library-config/src/otel_process_ctx.rs

@@ -81,4 +81,5 @@ strum = { version = "0.26", features = ["derive"] }
 tempfile = "3"
 
 [build-dependencies]
+cc = "1.1.31"
 cxx-build = { version = "1.0", optional = true }

libdd-profiling/Cargo.toml

@@ -11,4 +11,20 @@ fn main() {
 
         println!("cargo:rerun-if-changed=src/cxx.rs");
     }
+
+    // Only compile the TLS shim on Linux; the thread-level context feature is Linux-only.
+    #[cfg(target_os = "linux")]
+    {
+        let mut build = cc::Build::new();
+
+        // - On aarch64, TLSDESC is already the only dynamic TLS model so no flag is needed.
+        // - On x86-64, we use `-mtls-dialect=gnu2` (supported since GCC 4.4 and Clang 19+) to force
+        //   the use of TLSDESC as mandated by the spec. If it's not supported, this build will
+        //   fail.
+        #[cfg(target_arch = "x86_64")]
+        build.flag("-mtls-dialect=gnu2");
+
+        build.file("src/tls_shim.c").compile("tls_shim");
+        println!("cargo:rerun-if-changed=src/tls_shim.c");
+    }
 }

libdd-profiling/build.rs

@@ -14,5 +14,6 @@ pub mod cxx;
 pub mod exporter;
 pub mod internal;
 pub mod iter;
+pub mod otel_thread_ctx;
 pub mod pprof;
 pub mod profiles;