refactor(got-patching): extract shared GOT-patching primitives into libdd-got-hook by gyuheon0h · Pull Request #2282 · DataDog/libdatadog

gyuheon0h · 2026-07-27T19:04:27Z

Stacked under feat(got-hook): add DT_HASH fallback, relocation type guard, and hook_symbol

What does this PR do?

Moves the ELF GOT-patching infrastructure out of libdd-profiling-heap-gotter into a new shared crate libdd-got-hook, so multiple crates can reuse the same machinery for runtime function interposition.

This is a pure code move. I tried to have no behavioral changes here.

What moves to libdd-got-hook

DynamicInfo::from_phdr: parse PT_DYNAMIC from a loaded ELF object
gnu_hash / gnu_hash_symbol_count / gnu_hash_lookup / check_sym: GNU hash table utilities
iterate_libraries: this is a dl_iterate_phdr wrapper with panic-safe trampoline
PageProtGuard / read_proc_maps / MapEntry: RELRO-aware page protection management
lookup_symbol / LookupResult: used for resolving a symbol across all loaded objects
elf64_r_sym: relocation info helper
ELF types and constants

What stays in libdd-profiling-heap-gotter

SymbolOverrides: multi-symbol registry
hooks.rs: the actual malloc/free/calloc/realloc hook functions
lib.rs: install_heap_overrides / update_heap_overrides public API

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 · 2026-07-27T19:04:43Z

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

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

datadog-official · 2026-07-27T19:12:34Z

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 88.34%
• Overall Coverage: 74.99% (-0.20%)

_{This comment will be updated automatically if new data arrives.

🔗 Commit SHA: 5509c44 | Docs | Datadog PR Page | Give us feedback!}

dd-octo-sts · 2026-07-27T19:53:15Z

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	8.01 MB	8.01 MB	0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	87.32 MB	87.37 MB	+.05% (+50.66 KB) 🔍

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	98.55 MB	98.50 MB	--.05% (-51.03 KB) 💪
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.78 MB	10.78 MB	+.01% (+1.20 KB) 🔍

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	26.05 MB	26.04 MB	--.01% (-3.00 KB) 💪
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	89.60 KB	89.60 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	188.07 MB	188.06 MB	-0% (-8.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	980.68 MB	980.60 MB	-0% (-77.18 KB) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	8.49 MB	8.49 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	89.60 KB	89.60 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	25.10 MB	25.10 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	49.92 MB	49.92 MB	+0% (+1.21 KB) 👌

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	22.69 MB	22.68 MB	--.04% (-9.50 KB) 💪
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	91.00 KB	91.00 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	192.83 MB	192.82 MB	-0% (-8.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	969.32 MB	970.09 MB	+.08% (+797.29 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	6.56 MB	6.56 MB	+.02% (+1.50 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	91.00 KB	91.00 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	26.97 MB	26.98 MB	+.02% (+8.00 KB) 🔍
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	47.53 MB	47.54 MB	+.01% (+7.69 KB) 🔍

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	77.87 MB	77.77 MB	--.13% (-104.87 KB) 💪
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	8.93 MB	8.93 MB	--.04% (-4.00 KB) 💪

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	93.36 MB	93.39 MB	+.03% (+33.86 KB) 🔍
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.87 MB	10.87 MB	-0% (-984 B) 👌

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 822405c2e5

ℹ️ 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".

pr-commenter · 2026-07-27T20:12:24Z

Benchmarks

Comparison

Benchmark execution time: 2026-08-04 13:56:13

Comparing candidate commit 5509c44 in PR branch gyuheon0h/extract-got-hook-crate with baseline commit 38a1987 in branch main.

Found 24 performance improvements and 18 performance regressions! Performance is the same for 98 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:msgpack_decoder::v05/low_sharing/10000

🟥 execution_time [+768.581µs; +773.948µs] or [+4.464%; +4.495%]
🟥 throughput [-24984.886op/s; -24809.890op/s] or [-4.302%; -4.272%]

scenario:msgpack_decoder::v05/low_sharing/200

🟥 execution_time [+15.978µs; +16.208µs] or [+4.593%; +4.659%]
🟥 throughput [-25598.765op/s; -25234.547op/s] or [-4.453%; -4.390%]

scenario:msgpack_decoder::v05/low_sharing/2000

🟥 execution_time [+169.902µs; +171.041µs] or [+4.920%; +4.953%]
🟥 throughput [-27340.573op/s; -27155.575op/s] or [-4.721%; -4.689%]

scenario:normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...

🟩 execution_time [-19.875µs; -19.722µs] or [-9.648%; -9.575%]
🟩 throughput [+514331.800op/s; +518089.758op/s] or [+10.594%; +10.672%]

scenario:normalization/normalize_name/normalize_name/bad-name

🟩 execution_time [-1.950µs; -1.854µs] or [-10.119%; -9.621%]
🟩 throughput [+5538251.401op/s; +5796514.310op/s] or [+10.669%; +11.167%]

scenario:normalization/normalize_name/normalize_name/good

🟩 execution_time [-1.672µs; -1.651µs] or [-14.176%; -13.998%]
🟩 throughput [+13819644.831op/s; +13985450.942op/s] or [+16.297%; +16.493%]

scenario:normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...

🟩 execution_time [-36.203µs; -35.971µs] or [-6.768%; -6.725%]
🟩 throughput [+134801.777op/s; +135686.713op/s] or [+7.211%; +7.258%]

scenario:normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters

🟩 execution_time [-19.477µs; -19.359µs] or [-10.252%; -10.190%]
🟩 throughput [+597503.882op/s; +600952.927op/s] or [+11.352%; +11.417%]

scenario:normalization/normalize_service/normalize_service/test_ASCII

🟥 execution_time [+2.809µs; +2.872µs] or [+6.165%; +6.303%]
🟥 throughput [-1302595.739op/s; -1273643.189op/s] or [-5.935%; -5.803%]

scenario:profiles_dictionary/profile_string_inserts/threads/1

🟥 execution_time [+13.457µs; +18.337µs] or [+4.443%; +6.055%]
🟥 throughput [-192993.453op/s; -143454.299op/s] or [-5.708%; -4.243%]

scenario:vec_map/as_deduped_map/already_deduped/16

🟥 execution_time [+9.250ns; +9.283ns] or [+38.354%; +38.490%]

scenario:vec_map/as_deduped_map/already_deduped/8

🟥 execution_time [+1.202ns; +1.237ns] or [+8.306%; +8.545%]

scenario:vec_map/contains_key/128

🟩 execution_time [-716.111ns; -708.912ns] or [-4.571%; -4.525%]
🟩 throughput [+387238.719op/s; +391195.524op/s] or [+4.740%; +4.788%]

scenario:vec_map/contains_key/16

🟩 execution_time [-30.959ns; -30.669ns] or [-11.807%; -11.696%]
🟩 throughput [+8085875.063op/s; +8166259.093op/s] or [+13.251%; +13.383%]

scenario:vec_map/contains_key/64

🟩 execution_time [-246.051ns; -243.348ns] or [-5.876%; -5.811%]
🟩 throughput [+943208.409op/s; +953997.550op/s] or [+6.171%; +6.242%]

scenario:vec_map/contains_key/8

🟩 execution_time [-12.951ns; -12.624ns] or [-15.561%; -15.168%]
🟩 throughput [+17226795.033op/s; +17666114.711op/s] or [+17.920%; +18.377%]

scenario:vec_map/get_hit/128

🟥 execution_time [+1.141µs; +1.149µs] or [+9.123%; +9.188%]
🟥 throughput [-861054.899op/s; -855091.033op/s] or [-8.416%; -8.358%]

scenario:vec_map/get_hit/16

🟩 execution_time [-12.382ns; -12.193ns] or [-5.834%; -5.745%]
🟩 throughput [+4597891.967op/s; +4667131.562op/s] or [+6.099%; +6.191%]

scenario:vec_map/get_hit/64

🟥 execution_time [+238.394ns; +242.468ns] or [+7.064%; +7.185%]
🟥 throughput [-1271686.828op/s; -1250896.401op/s] or [-6.705%; -6.596%]

scenario:vec_map/get_hit/8

🟩 execution_time [-7.688ns; -7.525ns] or [-12.493%; -12.227%]
🟩 throughput [+18149519.963op/s; +18494292.364op/s] or [+13.961%; +14.226%]

scenario:vec_map/get_miss/128

🟥 execution_time [+5.104ns; +5.208ns] or [+6.665%; +6.801%]

scenario:vec_map/get_miss/16

🟩 execution_time [-18.683ns; -18.448ns] or [-68.249%; -67.391%]

scenario:vec_map/get_miss/64

🟥 execution_time [+5.450ns; +5.551ns] or [+10.696%; +10.894%]

scenario:vec_map/get_miss/8

🟩 execution_time [-12.930ns; -12.754ns] or [-71.495%; -70.525%]

Benchmark execution time: 2026-08-04 14:05:17

Comparing candidate commit 5509c44 in PR branch gyuheon0h/extract-got-hook-crate with baseline commit 38a1987 in branch main.

Found 19 performance improvements and 26 performance regressions! Performance is the same for 123 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/16

🟩 execution_time [-1.418ns; -1.375ns] or [-9.043%; -8.773%]

scenario:alloc_free/system/256

🟩 execution_time [-1.357ns; -1.318ns] or [-8.680%; -8.430%]

scenario:alloc_free/system/4096

🟥 execution_time [+11.379ns; +11.529ns] or [+12.035%; +12.193%]

scenario:alloc_free/system/64

🟩 execution_time [-1.397ns; -1.354ns] or [-8.880%; -8.607%]

scenario:credit_card/is_card_number/ 3782-8224-6310-005

🟥 execution_time [+3.547µs; +3.744µs] or [+4.589%; +4.844%]
🟥 throughput [-599828.322op/s; -567232.861op/s] or [-4.636%; -4.384%]

scenario:credit_card/is_card_number/ 378282246310005

🟥 execution_time [+6.074µs; +6.171µs] or [+8.971%; +9.114%]
🟥 throughput [-1233545.922op/s; -1215442.586op/s] or [-8.352%; -8.230%]

scenario:credit_card/is_card_number/378282246310005

🟥 execution_time [+5.940µs; +6.020µs] or [+9.176%; +9.300%]
🟥 throughput [-1314292.376op/s; -1298066.641op/s] or [-8.508%; -8.403%]

scenario:credit_card/is_card_number/37828224631000521389798

🟥 execution_time [+8.140µs; +8.175µs] or [+18.082%; +18.159%]
🟥 throughput [-3415188.528op/s; -3400351.552op/s] or [-15.374%; -15.308%]

scenario:credit_card/is_card_number/x371413321323331

🟥 execution_time [+742.778ns; +745.477ns] or [+13.017%; +13.064%]
🟥 throughput [-20252026.743op/s; -20179054.399op/s] or [-11.557%; -11.515%]

scenario:credit_card/is_card_number_no_luhn/ 3782-8224-6310-005

🟥 execution_time [+4.204µs; +4.369µs] or [+6.902%; +7.173%]
🟥 throughput [-1102738.911op/s; -1058892.461op/s] or [-6.716%; -6.449%]

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

🟥 execution_time [+4.665µs; +4.713µs] or [+8.677%; +8.766%]
🟥 throughput [-1499486.178op/s; -1484352.634op/s] or [-8.062%; -7.981%]

scenario:credit_card/is_card_number_no_luhn/378282246310005

🟥 execution_time [+5.187µs; +5.241µs] or [+10.305%; +10.411%]
🟥 throughput [-1873266.801op/s; -1855430.082op/s] or [-9.430%; -9.340%]

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

🟥 execution_time [+8.006µs; +8.049µs] or [+17.790%; +17.886%]
🟥 throughput [-3372132.950op/s; -3355031.863op/s] or [-15.176%; -15.099%]

scenario:credit_card/is_card_number_no_luhn/x371413321323331

🟥 execution_time [+743.505ns; +746.272ns] or [+13.029%; +13.078%]
🟥 throughput [-20270830.337op/s; -20198008.556op/s] or [-11.567%; -11.526%]

scenario:datadog_sample_span/name_pattern_rule_not_matching/wall_time

🟥 execution_time [+33.417ns; +33.596ns] or [+21.172%; +21.286%]

scenario:ddsketch_read/ordered_bins/clustered_near_zero

🟩 execution_time [-234.921ns; -232.079ns] or [-4.158%; -4.107%]

scenario:ddsketch_read/ordered_bins/collapsing

🟩 execution_time [-1.968µs; -1.957µs] or [-7.559%; -7.518%]

scenario:ddsketch_read/ordered_bins/mixed

🟩 execution_time [-870.357ns; -863.164ns] or [-7.584%; -7.521%]

scenario:glob_matcher/ascii_case_insensitive_match/wall_time

🟩 execution_time [-2.093ns; -2.078ns] or [-7.068%; -7.016%]

scenario:glob_matcher/ascii_exact_match/wall_time

🟩 execution_time [-2.086ns; -2.061ns] or [-7.044%; -6.962%]

scenario:glob_matcher/ascii_exact_miss/wall_time

🟩 execution_time [-2.420ns; -2.366ns] or [-16.281%; -15.921%]

scenario:no_profiler/short_circuit/16

🟩 execution_time [-16.471ns; -16.436ns] or [-39.003%; -38.920%]

scenario:no_profiler/short_circuit/256

🟩 execution_time [-16.505ns; -16.471ns] or [-39.084%; -39.005%]

scenario:no_profiler/short_circuit/4096

🟩 execution_time [-11.662ns; -11.487ns] or [-10.294%; -10.141%]

scenario:no_profiler/short_circuit/64

🟩 execution_time [-16.462ns; -16.432ns] or [-38.996%; -38.923%]

scenario:no_profiler/short_circuit/65536

🟩 execution_time [-10.443ns; -10.314ns] or [-9.462%; -9.345%]

scenario:profiler_attached/slow_path_system/16

🟩 execution_time [-15.813ns; -15.747ns] or [-14.914%; -14.851%]

scenario:profiler_attached/slow_path_system/256

🟩 execution_time [-18.679ns; -18.627ns] or [-17.167%; -17.119%]

scenario:profiler_attached/slow_path_system/4096

🟩 execution_time [-20.853ns; -20.698ns] or [-11.895%; -11.807%]

scenario:profiler_attached/slow_path_system/64

🟩 execution_time [-16.578ns; -16.398ns] or [-15.535%; -15.366%]

scenario:profiler_attached/slow_path_system/65536

🟩 execution_time [-20.784ns; -20.659ns] or [-11.730%; -11.659%]

scenario:redis/obfuscate_redis_string

🟥 execution_time [+2.605µs; +3.080µs] or [+8.070%; +9.540%]

scenario:sql/obfuscate_sql_string

🟥 execution_time [+22.327µs; +22.583µs] or [+7.867%; +7.957%]

scenario:trace_buffer/4_senders/no_delay

🟥 execution_time [+166.489µs; +195.027µs] or [+7.140%; +8.364%]
🟥 throughput [-121663.307op/s; -103366.968op/s] or [-7.869%; -6.686%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

scottgerring · 2026-07-28T05:55:37Z

Hey @gyuheon0h cool - this is a good idea! We don't want to end up maintaining N variants of this sort of thing.
Happy to review this but it will have to wait til next week; i'll regress it against all my stuff just to be extra sure before we merge and this week is hectic. For the new hashing modes, you'll want to make sure you test against real binaries linked in this fashion.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ced5999cd0

ℹ️ 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".

scottgerring · 2026-07-29T09:53:15Z

Nice - I wanted to do this! Will review first thing Monday 💪 Please don't merge beforehand as I'd like to double check all the allocation profiling stuff that rests on it.

gyuheon0h · 2026-07-29T15:34:21Z

@yannham @scottgerring Ill just stack another PR on top of this with the new changes, so that this PR strictly only focuses on the initial "no new feature" refactor 👍

scottgerring

Hey @gyuheon0h , thanks for taking the time to split this out and make it re-usable! 🙌
Apart from a handful of nits, I think the two things to agree on are the name of the crate (some suggestions inline) and the shape of the API introduced around DynamicInfo

scottgerring · 2026-07-31T11:16:54Z

+/// currently-loaded ELF object.
+pub unsafe fn gnu_hash_lookup(info: &DynamicInfo, name: &[u8]) -> Option<Elf64_Sym> {
+    let hashtab = info.gnu_hash;
+    if hashtab.is_null() || info.gnu_hash_words < 4 {


Extra defensive check welcome!

scottgerring · 2026-07-31T11:25:29Z

+    }
+
+    /// Access to REL relocations (pointer, count).
+    pub fn rels(&self) -> (*const Elf64_Rel, usize) {


I'm not sure the accessors here are adding much apart from indirection; this is just pushing the unsafe outwards.

I think something like this would be better as it adapts to a safe API and unburdens the caller, but I am also interested in what @yannham thinks:

pub unsafe fn rels(&self) -> Option<&[Elf64_Rel]>

.. basically if we're going to change this in the mechanical refactoring bit, we may as well deal with the null check and slice construction in the API itself.

Yeah, I agree a slice API would be nice. I guess we can even make it safe if the ELF ABI guarantees that a well-formed Elf file will have an array-like layout for self.rels (and check for nulls here).

scottgerring

LGTM! Thanks for addressing comments. Suggest addressing continued feedback on "how we can make this better" in the stacked PR.

Move the ELF parsing, dl_iterate_phdr iteration, PageProtGuard, gnu_hash_symbol_count, gnu_hash_lookup, lookup_symbol, and related utilities out of libdd-profiling-heap-gotter into a new libdd-got-hook crate. libdd-profiling-heap-gotter now depends on libdd-got-hook and keeps only the SymbolOverrides multi-symbol registry and per-library dedup/rescan logic. This is a pure code move — no behavioral changes.

realFlowControl

Had one comment, that might be dd-trace-php specific and is not a blocker to merging this PR.

github-actions · 2026-08-04T13:20:35Z

📚 Documentation Check Results

⚠️ 234 documentation warning(s) found

📦 `libdd-gotter` - 6 warning(s)

📦 `libdd-profiling-heap-gotter` - 55 warning(s)

📦 `tools` - 173 warning(s)

Updated: 2026-08-04 13:20:34 UTC | Commit: 4e8b29b | missing-docs job results

github-actions · 2026-08-04T13:22:27Z

🔒 Cargo Deny Results

⚠️ 3 issue(s) found, showing only errors (advisories, bans, sources)

📦 `libdd-gotter` - ✅ No issues

📦 `libdd-profiling-heap-gotter` - ✅ No issues

📦 `tools` - 3 error(s)

Show output

error[vulnerability]: Quadratic run time when checking a start tag for duplicate attribute names
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:72:1
   │
72 │ quick-xml 0.37.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0194
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0194
   ├ `BytesStart::attributes()` returns an `Attributes` iterator which, by default
     (`with_checks(true)`), rejects a start tag that repeats an attribute name. For
     each attribute yielded, the iterator compared the new name against every name
     seen so far in the same tag using a linear scan, so a start tag with `N`
     distinct attribute names cost `O(N²)` byte comparisons. There was no bound on
     `N` other than the size of the buffered start tag.
     
     ## Impact
     
     Any code that parses untrusted XML and iterates a start tag's attributes with
     the default duplicate check enabled can be made to spend CPU time quadratic in
     the number of attributes on a single tag. Because the check is pure computation
     with no `.await`/I/O, an I/O-based timeout on the consumer (for example a read
     or request timeout) cannot interrupt it while it runs.
     
     Measured cost of a single start tag, release build:
     
     | Attributes on one tag | Time |
     |---|---|
     | 80,000  | ~6 s   |
     | 800,000 | ~10 min |
     
     The cost grows with the square of the attribute count, so a start tag of a few
     tens of megabytes can stall a parsing thread for hours. No memory is exhausted
     and the parser does not crash; the effect is CPU exhaustion on the thread doing
     the parsing: a single crafted start tag can pin a CPU core for minutes to hours,
     denying service to that worker. A deployment that places a wall-clock bound on
     parsing, or confines it to a non-critical thread, may consider the availability
     impact lower.
     
     ## Affected code paths
     
     * `BytesStart::attributes()` / `Attributes` iterated with checks enabled (the
       default), and `BytesStart::try_get_attribute`.
     * `NsReader`, which resolves namespaces by iterating a tag's attributes and so
       reaches the same check internally.
     
     Consumers that iterate attributes with `.attributes().with_checks(false)` and do
     not use `NsReader` are not affected.
     
     This was reported as reachable by a remote, unauthenticated attacker in a
     real-world RPKI relying party (NLnet Labs Routinator) via a crafted RRDP
     `snapshot.xml`.
     
     ## Remediation
     
     Upgrade to `quick-xml >= 0.41.0`, where the duplicate check keeps the linear
     scan for start tags with a small number of attributes and switches to an `O(1)`
     hash pre-filter above a threshold, making the whole tag `O(N)`. The reported
     `AttrError::Duplicated` positions are unchanged.
     
     If upgrading is not possible and duplicate-name detection is not required,
     disable it with `.attributes().with_checks(false)` (this does not help
     `NsReader` consumers, which have no equivalent opt-out before 0.41.0).
   ├ Announcement: https://github.com/tafia/quick-xml/issues/969
   ├ Solution: Upgrade to >=0.41.0 (try `cargo update -p quick-xml`)
   ├ quick-xml v0.37.5
     └── tools v38.0.0

error[vulnerability]: Unbounded namespace-declaration allocation in `NsReader` enables memory-exhaustion denial of service
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:72:1
   │
72 │ quick-xml 0.37.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0195
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0195
   ├ `NsReader` resolves namespaces by calling `NamespaceResolver::push` for every
     `Start`/`Empty` event *before* the event is returned to the caller. `push`
     iterated all `xmlns` / `xmlns:*` attributes on the start tag and, for each one,
     appended the prefix bytes to an internal buffer and pushed a `NamespaceBinding`
     (32 bytes on 64-bit) to an internal `Vec`, with no upper bound on the number of
     declarations.
     
     ## Impact
     
     A start tag with `N` namespace declarations drove roughly `3×` the tag's byte
     size in `NamespaceResolver` heap, allocated *inside* `quick-xml` before the
     `NsReader` consumer ever received the event and could inspect or reject it. A
     consumer that bounds its *input* size therefore still cannot bound this
     allocation: an `M`-byte start tag yields on the order of `3 × M` bytes of
     resolver heap the caller never sees.
     
     On untrusted XML this lets a remote, unauthenticated attacker force large heap
     allocations with a single start tag. With several `NsReader`s running
     concurrently on independent inputs (a common server pattern), the allocations
     stack and can exhaust process memory, causing the operating system to kill the
     process (OOM). This was confirmed against a real-world RPKI relying party (NLnet
     Labs Routinator), where concurrent RRDP validation workers parsing a crafted
     `snapshot.xml` exceeded the memory limit and the process was OOM-killed.
     
     ## Affected code paths
     
     Consumers using `NsReader` (which always calls `NamespaceResolver::push` before
     yielding `Start`/`Empty`), or calling `NamespaceResolver::push` directly. A plain
     `Reader` that does not perform namespace resolution is not affected.
     
     ## Remediation
     
     Upgrade to `quick-xml >= 0.41.0`. `NamespaceResolver::push` now rejects a start
     tag that declares more than `DEFAULT_MAX_DECLARATIONS_PER_ELEMENT` (256)
     namespace bindings, returning the new `NamespaceError::TooManyDeclarations`
     instead of allocating without limit. The limit is configurable via
     `NamespaceResolver::set_max_declarations_per_element` (use `usize::MAX` to
     restore the previous unbounded behavior), and `NsReader::resolver_mut()` is
     provided to reach it.
     
     There is no clean workaround for `NsReader` consumers before 0.41.0, as the
     allocation happens inside the reader with no configuration knob to cap it.
   ├ Announcement: https://github.com/tafia/quick-xml/issues/970
   ├ Solution: Upgrade to >=0.41.0 (try `cargo update -p quick-xml`)
   ├ quick-xml v0.37.5
     └── tools v38.0.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:75:1
   │
75 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2026-0097
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
   ├ It has been reported (by [@lopopolo](https://github.com/lopopolo)) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
     
     - The `log` and `thread_rng` features are enabled
     - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
     - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
     - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
     - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
     
     `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
   ├ Announcement: https://github.com/rust-random/rand/pull/1763
   ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
   ├ rand v0.8.5
     └── (dev) libdd-common v5.1.0
         └── tools v38.0.0

advisories FAILED, bans ok, sources ok

Updated: 2026-08-04 13:22:27 UTC | Commit: 4e8b29b | dependency-check job results

gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 63b2fca to 60c1e60 Compare July 27, 2026 19:14

gyuheon0h mentioned this pull request Jul 27, 2026

feat(crashtracking)!: retrieve c assert message for linux when __assert_fail is dynamically loaded #2268

Draft

gyuheon0h changed the title ~~refactor: extract shared GOT-patching primitives into libdd-got-hook~~ refatcor(got-patching): extract shared GOT-patching primitives into libdd-got-hook Jul 27, 2026

github-actions Bot added the ci-build label Jul 27, 2026

gyuheon0h changed the title ~~refatcor(got-patching): extract shared GOT-patching primitives into libdd-got-hook~~ refactor(got-patching): extract shared GOT-patching primitives into libdd-got-hook Jul 27, 2026

gyuheon0h marked this pull request as ready for review July 27, 2026 20:00

gyuheon0h requested review from a team as code owners July 27, 2026 20:00

gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 822405c to 6ab7768 Compare July 27, 2026 20:01

chatgpt-codex-connector Bot reviewed Jul 27, 2026

View reviewed changes

Comment thread libdd-got-hook/src/elf.rs Outdated

Comment thread libdd-got-hook/src/elf.rs Outdated

Comment thread libdd-got-hook/src/elf.rs Outdated

gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 6ab7768 to 285cdd3 Compare July 27, 2026 20:06

gyuheon0h marked this pull request as draft July 27, 2026 21:07

gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 978bf00 to 67df7e6 Compare July 28, 2026 02:36

scottgerring self-requested a review July 28, 2026 05:53

gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from ea56fb3 to ced5999 Compare July 28, 2026 13:40

gyuheon0h marked this pull request as ready for review July 28, 2026 14:25

chatgpt-codex-connector Bot reviewed Jul 28, 2026

View reviewed changes

Comment thread libdd-gotter/src/elf.rs

yannham reviewed Jul 28, 2026

View reviewed changes

Comment thread libdd-got-hook/src/lib.rs Outdated

Comment thread libdd-gotter/src/elf.rs

Comment thread libdd-gotter/Cargo.toml

Comment thread libdd-profiling-heap-gotter/Cargo.toml Outdated

Comment thread libdd-got-hook/Cargo.toml Outdated

gyuheon0h marked this pull request as draft July 29, 2026 15:30

gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from ced5999 to e9b992a Compare July 29, 2026 15:30

gyuheon0h mentioned this pull request Jul 29, 2026

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

Open

github-actions Bot removed the ci-build label Jul 29, 2026

gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 560d0a6 to 45c074d Compare July 29, 2026 19:22

github-actions Bot added the ci-build label Jul 29, 2026

gyuheon0h marked this pull request as ready for review July 29, 2026 19:47

gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 45c074d to 11a3920 Compare July 30, 2026 16:39

gyuheon0h requested a review from yannham July 30, 2026 19:11

yannham approved these changes Jul 31, 2026

View reviewed changes

Comment thread libdd-got-hook/Cargo.toml Outdated

scottgerring reviewed Jul 31, 2026

View reviewed changes

gyuheon0h requested a review from scottgerring July 31, 2026 17:49

gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch 2 times, most recently from 66e5b36 to 31e53ca Compare July 31, 2026 19:06

danielsn reviewed Jul 31, 2026

View reviewed changes

scottgerring approved these changes Aug 3, 2026

View reviewed changes

gyuheon0h added 3 commits August 3, 2026 17:36

Comment clarity and rename pkg

0a853a1

slice api

baeeae6

gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch 2 times, most recently from ad0f49a to cfc1baf Compare August 3, 2026 17:59

Safety comments, in code documentation, test for proc maps parsing

6966e28

gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from cfc1baf to 6966e28 Compare August 3, 2026 18:53

realFlowControl reviewed Aug 4, 2026

View reviewed changes

Comment thread libdd-gotter/src/elf.rs

iunanua reviewed Aug 4, 2026

View reviewed changes

Comment thread libdd-gotter/Cargo.toml Outdated

Initial reelase

5509c44

gyuheon0h force-pushed the gyuheon0h/extract-got-hook-crate branch from 4542644 to 5509c44 Compare August 4, 2026 13:18

gyuheon0h mentioned this pull request Aug 4, 2026

feat(gotter)!: add fn to hook symbol but exclude self #2312

Open

gyuheon0h requested a review from iunanua August 4, 2026 13:38

iunanua approved these changes Aug 4, 2026

View reviewed changes

gyuheon0h merged commit 94f123f into main Aug 4, 2026
58 checks passed

gyuheon0h deleted the gyuheon0h/extract-got-hook-crate branch August 4, 2026 14:11

Uh oh!

Conversation

gyuheon0h commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

Motivation

Additional Notes

How to test the change?

Uh oh!

gyuheon0h commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

datadog-official Bot commented Jul 27, 2026 • edited by datadog-prod-us1-5 Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dd-octo-sts Bot commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Artifact Size Benchmark Report

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pr-commenter Bot commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmarks

Comparison

Explanation

More details about the CI and significant changes

scenario:msgpack_decoder::v05/low_sharing/10000

scenario:msgpack_decoder::v05/low_sharing/200

scenario:msgpack_decoder::v05/low_sharing/2000

scenario:normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...

scenario:normalization/normalize_name/normalize_name/bad-name

scenario:normalization/normalize_name/normalize_name/good

scenario:normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...

scenario:normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters

scenario:normalization/normalize_service/normalize_service/test_ASCII

scenario:profiles_dictionary/profile_string_inserts/threads/1

scenario:vec_map/as_deduped_map/already_deduped/16

scenario:vec_map/as_deduped_map/already_deduped/8

scenario:vec_map/contains_key/128

scenario:vec_map/contains_key/16

scenario:vec_map/contains_key/64

scenario:vec_map/contains_key/8

scenario:vec_map/get_hit/128

scenario:vec_map/get_hit/16

scenario:vec_map/get_hit/64

scenario:vec_map/get_hit/8

scenario:vec_map/get_miss/128

scenario:vec_map/get_miss/16

scenario:vec_map/get_miss/64

scenario:vec_map/get_miss/8

Explanation

More details about the CI and significant changes

scenario:alloc_free/system/16

scenario:alloc_free/system/256

scenario:alloc_free/system/4096

scenario:alloc_free/system/64

scenario:credit_card/is_card_number/ 3782-8224-6310-005

scenario:credit_card/is_card_number/ 378282246310005

scenario:credit_card/is_card_number/378282246310005

scenario:credit_card/is_card_number/37828224631000521389798

scenario:credit_card/is_card_number/x371413321323331

scenario:credit_card/is_card_number_no_luhn/ 3782-8224-6310-005

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

scenario:credit_card/is_card_number_no_luhn/378282246310005

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

scenario:credit_card/is_card_number_no_luhn/x371413321323331

scenario:datadog_sample_span/name_pattern_rule_not_matching/wall_time

scenario:ddsketch_read/ordered_bins/clustered_near_zero

scenario:ddsketch_read/ordered_bins/collapsing

scenario:ddsketch_read/ordered_bins/mixed

scenario:glob_matcher/ascii_case_insensitive_match/wall_time

scenario:glob_matcher/ascii_exact_match/wall_time

scenario:glob_matcher/ascii_exact_miss/wall_time

scenario:no_profiler/short_circuit/16

gyuheon0h commented Jul 27, 2026 •

edited

Loading

gyuheon0h commented Jul 27, 2026 •

edited

Loading

datadog-official Bot commented Jul 27, 2026 •

edited by datadog-prod-us1-5 Bot

Loading

dd-octo-sts Bot commented Jul 27, 2026 •

edited

Loading

pr-commenter Bot commented Jul 27, 2026 •

edited

Loading

scottgerring commented Jul 28, 2026 •

edited

Loading