feat: cross-language LTO to inline C TLS shim into Rust FFI#1982
feat: cross-language LTO to inline C TLS shim into Rust FFI#1982yannham wants to merge 9 commits into
Conversation
📚 Documentation Check Results📦
|
Clippy Allow Annotation ReportComparing clippy allow annotations between branches:
Summary by Rule
Annotation Counts by File
Annotation Stats by Crate
About This ReportThis report tracks Clippy allow annotations for specific rules, showing how they've changed in this PR. Decreasing the number of these annotations generally improves code quality. |
🔒 Cargo Deny Results📦
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #1982 +/- ##
==========================================
+ Coverage 72.68% 72.71% +0.02%
==========================================
Files 451 452 +1
Lines 74255 74270 +15
==========================================
+ Hits 53971 54004 +33
+ Misses 20284 20266 -18
🚀 New features to boost your workflow:
|
🎉 All green!❄️ No new flaky tests detected 🎯 Code Coverage (details) 🔗 Commit SHA: 9227252 | Docs | Datadog PR Page | Give us feedback! |
Add an opt-in inline mode via the LIBDD_OTEL_THREAD_CTX_INLINE env var that uses cross-language LTO (clang + lld) to inline the C TLS shim directly into the Rust FFI functions, eliminating a function-call indirection on every TLS access. When the env var is set, build.rs validates that clang and a suitable LLD are available, compiles the C shim as LLVM bitcode (-flto=thin), and emits the linker flags needed for cross-language LTO. A companion build-optimized.sh wrapper sets the target-scoped RUSTFLAGS and env var. When the env var is absent, the previous behavior is preserved: the default cc compiles the shim with -mtls-dialect=gnu2 on x86-64, no LTO, no inlining. Also fixes #[cfg(target_os/arch)] in build scripts to use the correct CARGO_CFG_* env vars for cross-compilation correctness. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
After a successful build, verify with nm that the C TLS shim symbol was actually inlined away. Warns and exits 1 if inlining failed, or warns (but succeeds) if nm is not available. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
99d5622 to
88d7f6d
Compare
2a54297 to
9932cac
Compare
Deduplicate the function that locates the toolchain's bundled rust-lld by moving it into build_common, where both build scripts can reuse it. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
9932cac to
9227252
Compare
Artifact Size Benchmark Reportaarch64-alpine-linux-musl
aarch64-unknown-linux-gnu
libdatadog-x64-windows
libdatadog-x86-windows
x86_64-alpine-linux-musl
x86_64-unknown-linux-gnu
|
What does this PR do?
Add opt-in cross-language LTO so the C TLS shim (
libdd_get_otel_thread_ctx_v1) is inlined directly into the Rust FFI functions, eliminating a function-call indirection on every TLS access.The mode is controlled by the
LIBDD_OTEL_THREAD_CTX_INLINEenv var. Abuild-optimized.shwrapper script sets the env var and the target-scopedRUSTFLAGSneeded for cross-language LTO. Without the env var, the build behaves exactly as before.Motivation
The OTel thread-level context spec requires TLSDESC for the TLS variable, which forces us through a C shim since stable
rustcdoesn't expose TLS dialect control. This adds a function call on everyattach/detach. Cross-language LTO eliminates that call — theattachpath becomes justlea(TLSDESC desc) →call(resolver) →xchg(swap TLS slot).Benchmark results (median of 3 runs on x86-64):
Additional Notes
clangandlld(the toolchain's bundledrust-lldis used automatically).build.rscannot set rustc codegen flags (-Clinker-plugin-lto,-Clinker=clang) — those must come fromRUSTFLAGS.#[cfg(target_os/arch)]in build scripts are replaced with the correctCARGO_CFG_*env vars for cross-compilation correctness.How to test the change?