Re: [RFC PATCH v2 00/11] objtool/klp: DWARF-based cross-build symbol correlation

[Josh Poimboeuf]

On Wed, Nov 04, 2026 at 09:31:46PM +0800, Longjun Luo wrote: > Open Questions and Next Steps
> -----------------------------
> 
> This is a substantial change: 1,755 of the 4,010 added lines are tests,
> and about 1,300 implement the DWARF reader and identity layer. Before
> preparing a merge-ready series, I would like explicit maintainer guidance
> on how to stage its integration. My proposed sequence is:
> 
> - Submit Patches 1-3 separately with their regression tests.
> - Prepare the identity representation, DWARF reader, and ELF cross-checks
>   as a foundation that can be reviewed separately from twin matching.
> - Integrate the matching changes in Patches 7-10 together: reference
>   extension pairs repeated statics, and the reference checks reject
>   remaining ambiguous data references.
> - Submit the memory optimizations separately and pursue explicit state
>   annotations in a separate RFC.
> 
> This RFC retains upstream expectations for the three policy tests to
> make the behavior changes visible. For the merge-ready series, I will
> update their assertions to reflect the agreed policy and move Patch 11's
> tests alongside the changes they cover.
> 
> I plan to add triple-based DWARF correctness tests in upstream compilers,
> using known source definitions and optimization variants to check
> coverage, non-conflict, and attribution accuracy (with clones, pieces,
> anonymous scopes, and folding checked according to their respective
> semantics) without locking in a specific DIE layout or suffix scheme. My
> earlier bug reports and fixes on IPA-ICF, weak-override attribution, and
> assembly CU selection [2-6] provide concrete test inputs, and the same
> attribution model applies to consumers such as AutoFDO [7].
> 
> I would appreciate feedback on four questions:
> 
> 1. Would maintainers prefer to integrate the identity representation and
>    reader first, then evolve twin matching in a follow-up series, or keep
>    them together for integration?
> 2. Is constraining candidates by the identity triple and extending twins
>    via checksums and unchanged-function references the right foundation
>    for correlation, and how should the final ELF fallback be bounded?
> 3. Is the handling boundary in Case D reasonable, and should explicit
>    state annotations (such as `KLP_NEW_STATIC()` / `KLP_DEL_STATIC()`) be
>    pursued in a separate RFC?
> 4. How should we structure upstream compiler tests around the identity
>    triple to protect both DWARF producers and livepatch consumers?

There are a LOT of words in this cover letter.  The whole thing is a bit
overwhelming to try to review, much less answer these questions.  Please
don't use LLM-generated text, as it can be very difficult to follow.

Also, I noticed the cover letter has several back-references to v1,
adding to my confusion.  The cover letter should be self-contained, such
that a reviewer can easily understand what the patch series does without
first studying v1.

DWARF is the most controversial and complex part of this series.  Before
going there, we should look at whatever can be improved *without*
relying on DWARF.  That will then make it much easier to evaluate what
additional benefits can be provided by DWARF later on.

klp-build is very much a pragmatic tool, and most likely will never be
able to handle all possible AI-imagined edge cases.  It should always be
used with caution, with someone (or something) double checking its
results at the end.

I suggest splitting up the patch series, focusing on fixing the more
realistic and tractable issues first.  Maybe even one issue at a time.
Human reviewer attention is spread very thin right now, please make
legibility a top priority.

-- 
Josh