Hi Guys,

  I Following on from the fix for addr2line inconsistent behaviour, as
  reported in PR 30150, I am applying the attached patch to correct a
  related problem.  The issue is _bfd_elf_find_function() and its
  attempts to cache a previous result in order to speed up future
  lookups.  If the function is called successively with two addresses
  and the second address happens to lie within the region of the symbol
  discovered for the first address, then the cached value will be used,
  even if there is a better match available.  For example:

    % addr2line -fipae vmlinux 0xffffffff81002000 0xffffffff81002020
    0xffffffff81002000: hypercall_page at /tmp/linux-5.15.92/linux-5.15.92/arch/x86/kernel/../../x86/xen/xen-head.S:75
    0xffffffff81002020: hypercall_page at /tmp/linux-5.15.92/linux-5.15.92/arch/x86/kernel/../../x86/xen/xen-head.S:75

  The second result is wrong as there is an exact match for the
  0xffffffff8100202 address:

    % readelf --syms --wide vmlinux | grep -e hypercall_page -e xen_hypercall_mmu_update
        82: ffffffff81002020    32 FUNC    LOCAL  DEFAULT    1 xen_hypercall_mmu_update
    117144: ffffffff81002000  4096 NOTYPE  GLOBAL DEFAULT    1 hypercall_page

  The patch fixes the problem by checking to see if symbols beyond the
  target address lie within the region covered by the current best-fit,
  and if they do, reducing the size of the best fit so that it no longer
  overlaps.

  In addition the patch moves the logic for choosing a best fit into a
  separate inline function in order to make it simpler and easier to
  understand.

  Tested with no regressions on a large number of different toolchains.

Cheers
  Nick