fix(debuginfo): correct language detection for LTO-compiled binaries

[nsavoire]

Problem

LTO can produce compilation units (CUs) whose DW_AT_language does not reflect the true source language of the functions they contain. Two cases arise:

1. Artificial LTO CUs — e.g. a C++ language tag on a CU that contains C functions. A top-level subprogram in such a CU carries a cross-unit DW_AT_abstract_origin pointing to the real (partial) CU.

2. Cross-language LTO inlinees — e.g. a C function inlined into a Rust caller. The inlinee's DW_AT_abstract_origin references the C CU directly.

Implementation

UnitRef::resolve_entry_language(entry, depth)

New helper on UnitRef that follows DW_AT_abstract_origin chains recursively to find the authoritative CU language:

• Recurses into the referenced entry first to handle multi-level chains
• If no deeper reference yields a language, falls back to the referenced CU's own DW_AT_language for cross-unit references.
• Limits recursion to MAX_ABSTRACT_ORIGIN_DEPTH = 16 levels (matching the limit used by elfutils dwarf_attr_integrate) to guard against cycles or malformed DWARF.

DwarfUnit::resolve_function_language(entry, fallback_language)

Thin wrapper around resolve_entry_language on the unit's UnitRef, falling back to fallback_language when no cross-unit language is found (e.g. when DW_AT_abstract_origin points to a partial unit with no DW_AT_language).

parse_function / parse_inlinee

parse_function calls resolve_function_language to resolve the authoritative language for the top-level subprogram and passes it down through parse_function_children and parse_inlinee. parse_inlinee calls resolve_function_language again on its own entry so that cross-language inlinees (e.g. C inlined into Rust) override the enclosing function's language correctly.

Tests

Two regression tests added with real binary fixtures:

• test_lto_language_detection (libjemalloc.so.debug): verifies that je_tcache_arena_associate and malloc_mutex_trylock_final (both C functions in a library compiled with LTO) are detected as Language::C, not Language::Cpp.

• test_cross_language_lto_inlinee_language (cross_language_lto.debug): verifies that my_add (a C function inlined into a Rust binary via cross-language LTO) is detected as Language::C, not Language::Rust.

[nsavoire]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Bravo.

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

[buranmert]

i need to do quite a bit of research in order to properly review this, i'll go with approving-blindly 😅

do you expect more changes in symbolic in the future?
do you think we should automate symbolic upgrades in our related services? or manual upgrades are still okay?

[nsavoire]

i need to do quite a bit of research in order to properly review this, i'll go with approving-blindly 😅

do you expect more changes in symbolic in the future? do you think we should automate symbolic upgrades in our related services? or manual upgrades are still okay?

This is not an easy PR to review 😄
I don't expect more changes, so I think we can keep with manual update for now.
Currently dd_master is in bad shape and CI do not pass. I plan to first update dd_master to latest symbolic release (12.17.2) and merge my PR on top of it.