[anatasluo]

The DWARF5 reader introduced in dd1395a incorrectly adds the
current range-list base to DW_RLE_startx_endx, DW_RLE_startx_length
and DW_RLE_start_length, whose addresses are already absolute.

In a small GCC 16.2.1 DWARF5 reproducer, CU low_pc is zero, but a
DW_RLE_base_address entry sets a nonzero base before start_length.
The extra addition puts an inline range outside its parent, causing
the inline instance to be discarded.

Remove the extra additions, matching the existing DW_RLE_start_end
handling and leaving DW_RLE_offset_pair unchanged. The regression
covers all three affected kinds with zero and nonzero bases, plus
an offset-pair control.

The reproducer matches llvm-symbolizer in inline function chains and
line numbers at 47/47 tested byte addresses after the fix (16/47
before). The DWARF4 control is unchanged.

[anatasluo]

Hi @snehasish ,

We've been using AutoFDO extensively for performance evaluation and comparisons, and found several DWARF reader issues during that work.

Could you take a look at this PR, #268 and #269 when you have a chance?

My suggested merge order is #267, #268, then #269. The fixes are independent, but their tests touch the same part of addr2line_test.cc. After each merge, I'll rebase the remaining PRs and resolve any conflicts.

Could you also approve the pending CI runs?

Thanks!

[snehasish]

Thanks for the fixes.

Can you give me more context on the performance evaluations and comparisons --

• What workloads are you looking at? Are there performance improvements that can be attributed to these fixes?
• Based on the fixes I assume that you're interested in building with gcc not llvm? LLVM support is more mature and should have fewer issues.
• Have you considered using the llvm-profgen tool available in the llvm mainline instead?
• What is your methodology in finding these issues?

[anatasluo]

Hi @snehasish ,

Thanks for taking a look and enabling CI. Our work on DWARF-based source correlation grew out of a userspace livepatching project.

• Workloads and performance: We use database-related workloads for evaluation. Some constructed cases show gains from better profile attribution, but we haven't established a general benefit. For these three reader fixes, we've validated correctness but haven't isolated their performance impact.

• GCC and Clang: We use both. These PRs target create_gcov's legacy reader. We've submitted related debug-info fixes for GCC, such as GCC PR126348, and for Clang/LLVM, such as LLVM #225358. We've also submitted a DWARF proposal on definition addresses after linkage selection.

• llvm-profgen: Our current experiments use create_gcov for GCC and create_llvm_prof for Clang. Thanks for suggesting llvm-profgen; it would be a useful additional comparison.

• Finding the issues: They came up while developing DWARF-related tooling, checking source attribution and reading AutoFDO's code. We then built small reproducers, checked the DWARF semantics, compared with LLVM/GNU symbolizers where applicable, and added regression tests that fail before the fixes and pass afterwards.

[snehasish]

For LLVM #225358 - IR inst merging is somewhat limited. You could try the "-pick-merged-source-locations" where one arbitrary but deterministic debug location will be picked instead of the debug loc being dropped.

There are certain optimizations which degrade debug info more than others. This paper we published recently may also be interesting for your work: https://snehasish.net/assets/pdf/assaiante-cgo26.pdf

[anatasluo]

Hi, @snehasish

Thanks for the suggestion and the paper. We tried a similar AutoFDO setup on nginx using llvm-profgen. Across six preliminary measurement rounds, final builds using profiles from O2-d7 and, separately, from O2 with -pick-merged-source-locations both achieved about 1.25% higher RPS than the O2-AutoFDO baseline. This exceeded the difference we observed between builds trained on two independently collected O2 profiles. O2-d3 showed no clear gain, while O2-d9 regressed. The pick sampling binary had byte-identical .text to O2, making that comparison particularly interesting.

Our work is complementary: we focus on correct profile attribution and matching across builds, drawing on our userspace livepatching research. We have seen performance gains in some experiments, but more accurate attribution does not always translate into better performance. In one database workload, correcting attribution changed inlining decisions and reduced branch misses per transaction, yet throughput fell. The occasional regressions discussed in the paper therefore caught our attention too.

Your work has been very helpful to us. We plan to evaluate how much additional performance AutoFDO can gain by combining better debug information with more accurate profile matching, while keeping the workload and perf sampling settings fixed.

[snehasish]

we focus on correct profile attribution and matching across builds, drawing on our userspace livepatching research

That sounds very interesting, you might want to take a look at this recent paper: https://takhandipu.github.io/papers/bhuiyan-wax-asplos-2026.pdf

It is evaluated on BOLT but some of the ideas (for function name fuzzy matching) are applicable for AutoFDO / SamplePGO. LLVM has a couple of flags defined in SampleProfile.cpp which are related: -salvage-stale-profile and -salvage-unused-profile.

Feel free to reach out to me directly or on discourse and I'll happy to answer questions etc.