DI: add a C extension

[p-datadog]

What does this PR do?
Adds two C extension functions to libdatadog_api for Dynamic Instrumentation:

1. all_iseqs: returns RubyVM::InstructionSequence objects for loaded code, needed for instrumenting third-party code with line probes. Not yet wired into instrumentation — that happens in DI: backfill CodeTracker registry with iseqs for pre-loaded files #5496.
2. exception_message: returns the raw argument passed to the Exception constructor, bypassing any Ruby-level message method overrides.

Integrates exception_message into ProbeNotificationBuilder so method probe snapshots now populate the throwable field (type, message, stacktrace).

The C extension is now a hard requirement for DI — environment_supported? checks for it, and the new code calls it directly with no fallback.

DI specs under spec/datadog/di/ are moved from spec:main to the new spec:di:di_with_ext task, which compiles the extension before running tests. The task is added to the Matrixfile so CI runs them.

Motivation:

• Line probes require iseq objects that the VM does not expose to Ruby code; the C extension provides access.
• DI must never invoke customer code; exception_message accesses the raw C-level message, bypassing overridden message methods.
• The C extension always compiles on MRI (the only platform DI supports), so there is no need for fallback code paths. Making it a hard requirement simplifies the codebase and makes failures explicit.

Change log entry
Yes. Dynamic Instrumentation: exception messages are now safely reported in method probe snapshots. The libdatadog_api C extension is now required for Dynamic Instrumentation.

Additional Notes:
The C code lives in the existing libdatadog_api extension (does not use libdatadog itself — this avoids creating another extension).

An error boundary is added around probe_executed_callback in method probes so DI errors never propagate to or replace customer exceptions.

Non-string exception constructor arguments are reported as <REDACTED: not a string value> rather than calling .to_s (which could invoke customer code). Nil arguments pass through as nil.

Follow-up work:

• Populate CodeTracker iseq registry with all_iseqs/file_iseqs to enable line probes on code loaded before DI starts (DI: backfill CodeTracker registry with iseqs for pre-loaded files #5496)
• Use trace_points field of iseqs to detect line probes targeting non-executable lines
• Report ranges of executable code to SymDB

How to test the change?
Unit tests added for C extension functions (all_iseqs, exception_message). Unit tests for serialize_throwable cover: exception present/absent, overridden message, non-string arg, nil arg. Integration test verifies full path from method probe exception capture through to snapshot with populated throwable. Manual verification screenshot included below.

Screenshot of a manual test with a non-string Exception argument:

[github-actions]

Thank you for updating Change log entry section 👏

^{Visited at: 2025-12-05 17:39:23 UTC}

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-03-27 16:34:19

Comparing candidate commit 6d63f39 in PR branch di-c-ext with baseline commit ec56ebe in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 46 metrics, 0 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

[datadog-datadog-prod-us1]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 99.53%
• Overall Coverage: 96.33% (+1.16%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 3539fa7 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!}

[ivoanjo]

The C code is in libdatadog_api extension, however it does not use libdatadog. This was done to not create another extension.

I think this is the right decision -- managing multiple extensions adds complexity AND makes installation slower.

[ivoanjo]

This is cool! Left a few notes :)

[p-datadog]

Thanks for confirming — glad the approach makes sense!

[Strech]

@codex Review for bugs and edge-cases

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b6577c28e9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".