feat(gotter)!: add DT_HASH fallback, relocation type guard, and hook_symbol

[gyuheon0h]

Stacked above refactor(got-patching): extract shared GOT-patching primitives into libdd-got-hook
Stacked under feat(crashtracking): retrieve c assert message for linux when __assert_fail is dynamically loaded

PROF-15629

What does this PR do?

Adds three general improvements to libdd-got-hook for crash tracking (and beneficial to heap profiling):

• DT_HASH (SysV) fallback: DynamicInfo::from_phdr no longer requires DT_GNU_HASH. Objects linked with --hash-style=sysvare now parsed by reading nchain from the SysV hash header. We jjust skipped these objects previously.
• Relocation type guard: elf64_r_type + is_got_pointer_reloc now only patches GLOB_DAT and JUMP_SLOT relocations (pointer-sized GOT slots) on both x86_64 and aarch64. Non-pointer relocation types are now skipped, preventing potential corruption of adjacent code/data from writing 8 bytes into a 4-byte relocation field. Applied to both libdd-got-hook's patch_got_entries and libdd-profiling-heap-gotter's process_relocation. (this was a codex recommendation)
• hook_symbol: Single-symbol convenience wrapper that combines dlsym + iterate_libraries + patch_got_entries into one call.

Motivation

What inspired you to submit this pull request?

Additional Notes

Gated on @scottgerring's approval

How to test the change?

Describe here in detail how the change can be validated.

[gyuheon0h]

• feat(gotter)!: add DT_HASH fallback, relocation type guard, and hook_symbol #2297 : 2 dependent PRs (#2268 , #2312 ) 👈 (View in Graphite)
• refactor(got-patching): extract shared GOT-patching primitives into libdd-got-hook #2282
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[datadog-prod-us1-3]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 74.67%
• Overall Coverage: 75.96% (+0.01%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 0fd2fba | Docs | Datadog PR Page | Give us feedback!}

[dd-octo-sts]

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	87.84 MB	87.84 MB	0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	8.07 MB	8.07 MB	0% (0 B) 👌

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.88 MB	10.88 MB	0% (0 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	98.97 MB	98.97 MB	0% (0 B) 👌

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	26.21 MB	26.21 MB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	89.92 KB	89.92 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	188.66 MB	188.66 MB	0% (0 B) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	985.57 MB	985.57 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	8.56 MB	8.56 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	89.92 KB	89.92 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	25.22 MB	25.22 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	50.23 MB	50.23 MB	0% (0 B) 👌

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	22.84 MB	22.84 MB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	91.33 KB	91.33 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	193.44 MB	193.43 MB	-0% (-8.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	974.34 MB	974.34 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	6.61 MB	6.61 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	91.33 KB	91.33 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	27.12 MB	27.12 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	47.83 MB	47.83 MB	0% (0 B) 👌

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	78.21 MB	78.21 MB	0% (0 B) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	9.00 MB	9.00 MB	0% (0 B) 👌

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	93.85 MB	93.85 MB	0% (0 B) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.97 MB	10.97 MB	0% (0 B) 👌

[pr-commenter]

Benchmarks

Comparison

Benchmark execution time: 2026-08-07 19:39:42

Comparing candidate commit 0fd2fba in PR branch gyuheon0h/got-hook-utils with baseline commit fbdace3 in branch main.

Found 0 performance improvements and 5 performance regressions! Performance is the same for 135 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 ----------------------------------'

scenario:profiles_dictionary/profile_string_inserts/threads/1

• 🟥 execution_time [+14.004µs; +18.411µs] or [+4.601%; +6.049%]
• 🟥 throughput [-192258.268op/s; -147535.681op/s] or [-5.714%; -4.385%]

scenario:vec_map/get_hit/8

• 🟥 execution_time [+3.532ns; +3.578ns] or [+6.550%; +6.636%]
• 🟥 throughput [-9232953.096op/s; -9118231.400op/s] or [-6.223%; -6.146%]

scenario:vec_map/get_miss/64

• 🟥 execution_time [+8.674ns; +8.766ns] or [+18.147%; +18.340%]

Benchmark execution time: 2026-08-07 19:46:39

Comparing candidate commit 0fd2fba in PR branch gyuheon0h/got-hook-utils with baseline commit fbdace3 in branch main.

Found 1 performance improvements and 8 performance regressions! Performance is the same for 159 metrics, 10 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 ----------------------------------'

scenario:alloc_free/system/4096

• 🟩 execution_time [-11.222ns; -11.017ns] or [-12.273%; -12.049%]

scenario:datadog_sample_span/name_pattern_rule_not_matching/wall_time

• 🟥 execution_time [+25.885ns; +26.003ns] or [+16.388%; +16.463%]

scenario:datadog_sample_span/resource_pattern_rule_matching/wall_time

• 🟥 execution_time [+11.339ns; +11.451ns] or [+4.367%; +4.410%]

scenario:no_profiler/short_circuit/4096

• 🟥 execution_time [+5.703ns; +5.863ns] or [+5.836%; +6.000%]

scenario:profiler_attached/fast_path_noop/16

• 🟥 execution_time [+2.858ns; +2.864ns] or [+19.745%; +19.789%]

scenario:profiler_attached/fast_path_noop/256

• 🟥 execution_time [+2.857ns; +2.863ns] or [+19.736%; +19.780%]

scenario:profiler_attached/fast_path_noop/4096

• 🟥 execution_time [+2.857ns; +2.864ns] or [+19.736%; +19.788%]

scenario:profiler_attached/fast_path_noop/64

• 🟥 execution_time [+2.856ns; +2.862ns] or [+19.729%; +19.772%]

scenario:profiler_attached/fast_path_noop/65536

• 🟥 execution_time [+2.860ns; +2.868ns] or [+19.764%; +19.814%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 934d93c530

ℹ️ About Codex in GitHub

Codex has been enabled to automatically 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 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Gate the relocation filter to supported architectures

On 64-bit Linux targets other than x86_64/aarch64, this crate still compiles and the GOT-patching APIs are active, but this shared predicate now admits only the x86_64/aarch64 relocation numbers. Architectures such as s390x, ppc64, or riscv64 use different GLOB_DAT/JUMP_SLOT values, so their import relocations are all skipped and installation can report success after resolving originals without actually patching any GOT entries. Either gate the Linux implementation to the supported architectures or add the architecture-specific constants.

Useful? React with 👍 / 👎.

[gyuheon0h]

@scottgerring

Also out of curiosity, did you see the older sysv hashing in the wild somewhere?

No. Unfortunately, its hard to see what customers are running for their elf hashing :( but as part of just making this library more robust, I thought it was worth to do haha

[gyuheon0h]

These safety points come from from_raw_parts contract

[scottgerring]

I think we could use get here to avoid the indexing, or, restructure to avoid double indexing - sym_name indexes into symtab anyway but then discards it; we could add a sym_entry accessor that returns the tuple (Elf64_Sym, &Cstr) and then use it to get both here

[gyuheon0h]

Ah, good idea. Will help with possibility of diverging also