Re: Commit: Better caching in elf_find_function

[Alan Modra <amodra@gmail.com>]

On Thu, Feb 23, 2023 at 05:26:19PM +0000, Nick Clifton via Binutils wrote:
> 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.

Failures are seen on mips targets.

mipsel-linux-gnu  +FAIL: MIPS PIC relocation 6 (MIPS16)
mipsel-linux-gnu  +FAIL: MIPS PIC relocation 7
mipsel-linux-gnu  +FAIL: MIPS PIC relocation 7 (microMIPS)

The first failure is due to this symbol
     4: 00000000     0 NOTYPE  LOCAL  DEFAULT [MIPS16]     1 $LCL
being chosen rather than
    11: 00000000    32 FUNC    GLOBAL DEFAULT [MIPS16]     1 foo
for an error on the first address of foo.  Even if the address fit is
better, I think a NOTYPE LOCAL ought to not be chosen over a
FUNC GLOBAL.

-- 
Alan Modra
Australia Development Lab, IBM