Re: [PATCH] bfd/dwarf2: break equal-range function ties by DIE offset, not pointer

I was running a bunch of tests in parallel and was getting inconsistent
results.  This turned out to be the issue, and fixed the results.

I was using the ai to help run the tests / debug.  I had to interact with
it through a few iterations to get here, and verify it doesn’t change
results .  Also the original commit message was overlay wordy.  So it’s not
a fully automated patch.

I did read the ai usage for gcc and feel that it being under 15 lines of
code / trivial usage and thought it fell under that.  Would qualify it for
legally trivial.  I could manually write the commit message.  It would
become less wordy, possibly not as clean.

Still learning the ropes of open source commits.  Thank you for reviewing.

Sincerely,

Sam Price


On Fri, Aug 21, 2026 at 7:38 AM Jan Beulich <[email protected]> wrote:

> On 18.08.2026 04:11, Sam Price wrote:
> > lookup_address_in_function_table picks the function with the smallest
> range
> > containing the address.  When two candidates have the same range -- an
> inlined
> > subroutine covering its containing subprogram exactly -- the tie was
> broken by
> > comparing the two funcinfo pointers.  Those come from bfd_zalloc, so the
> winner
> > tracked heap layout (a new objalloc chunk can land below the old one),
> and
> > addr2line named a different function from run to run on the same binary;
> only
> > the function and its inlined frames varied, never file and line.
> >
> > Order by unit_offset instead.  It does not move with the heap, and it
> restores
> > the pre-089e3718bd8 result: that algorithm walked the prepend-built
> > function_table and kept the last-parsed among equals, i.e. the greater
> DW_AT
> > offset.  An inlined subroutine's DIE is a child of its subprogram's, so
> it has
> > the greater offset and now wins every time -- the innermost routine, as
> > intended.  The offsets are unique within the one comp_unit these
> candidates
> > share.
> >
> > This only changes output that was already unstable: funcinfos are
> allocated in
> > increasing-offset scan order, so within a single chunk pointer order and
> offset
> > order agree and both rules pick the same function -- verified
> byte-identical
> > over 164k addresses across ten inlined binaries.  Forcing the divergence
> needs
> > a chunk placed below its predecessor, which test input cannot, so the
> added
> > dw2-inline-tie test is a regression pin (inverting the compare to <
> fails it),
> > not a trigger.
> >
> > bfd/
> >       * dwarf2.c (lookup_address_in_function_table): Break equal
> >       best_fit_len ties on funcinfo->unit_offset rather than on the
> >       funcinfo pointer.
> >
> > Signed-off-by: Samuel Price <[email protected]>
> > Co-Authored-By: Claude Opus 4.8 <[email protected]>
> > ---
> >  bfd/dwarf2.c                                     |   11 +
> >  binutils/testsuite/binutils-all/addr2line.exp    |    7 +
> >  binutils/testsuite/binutils-all/dw2-inline-tie.S |  186
> ++++++++++++++++++++++
> >  binutils/testsuite/binutils-all/dw2-inline-tie.d |   12 +
> >  4 files changed, 214 insertions(+), 2 deletions(-)
>
> This all looks good to me, if there wasn't the Co-Authored-By:. That, to
> me,
> suggests that part of the patch was AI-generated, which would be in
> conflict
> with [1].
>
> Nick - if Sam came back saying the patch itself wasn't co-authored by
> Claude,
> i.e. if this was more like an Assisted-by: tag, would that then be okay to
> accept without asking further questions? Further, had the tag been absent,
> I
> likely wouldn't have recognized any possible AI origin. Which puts under
> question how to actually put the policy into practical effect.
>
> Jan
>
> [1] https://sourceware.org/binutils/wiki/LLM_Generated_Content
>