From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id 1B858385840F for ; Fri, 24 Feb 2023 08:27:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1B858385840F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x62f.google.com with SMTP id q11so16271567plx.5 for ; Fri, 24 Feb 2023 00:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=UuvN92+G3J6ICw7sqhY2WujYjExG6cgZk2oTFJaLFdg=; b=bw3Pr3RjVRL2oFNGDItzewZVJCvigsKQy7NbvB5qTHGvFC2fxtqYrEvOktS3sLcwN6 sZxFvcPdFnDZbzzfZgUOyvFnaAmWicgGX0KdTgVXAz+qDLNoa9Hered53w1FoaaM5d+/ sw2Pq/OWfiRdedCSpX4/6M8L83RUx1jaKcg74lfX5D23MRwcd9JVAC8F4HP37SPhgEd9 bAc7xlh29Rlm3idXbvZlCQ5+alpkxSqZGb6gDGgWJD2hHncNRPe/A8QJDwgiJkAeiS2f M4gBK0YL0Iw9i14dqZVpjN//Q5Da9w2Zfrbi87f3mf4Ete0q0OQwFna+Yv9bbvelv7Gt jYGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UuvN92+G3J6ICw7sqhY2WujYjExG6cgZk2oTFJaLFdg=; b=ATGvXXUcVNwkeSFg8nGZdQTZSgLUxxarjdsdCxNWKg+5E7gCURL4lRZzEjN3RDKo/4 49fxCuwI5y4ZEdzx3Yd25HoEfc31ZW9h80E82m4ML5KGff0f3d5IEDp2u7+HL1gOvCvC 70HQdGidKh4+FK7ImrVYIR07zCqTpSVQu/NY6q/30+hzyJXqAIez22WwXytaGFUTs4xN XuOA3ZpLcWO5QhCkxQMQ1kAw7oll5z6EFrsjuZxFBMgWX0Yub2X8MhnWLzl1D2BwUve1 8KEAAUc3PCM4e2DAHAMZZqlcwRipEeTng2zH0hLBVVBTagOFcWl4naHiNLSJ5KErRZtt P5+Q== X-Gm-Message-State: AO0yUKVNxbkzhbACZqKQrXrn9akm3dMfuo8P3VL0/lLWrnLr21pMJ+cQ o7nE6dWRVstgQcd8Pz0PT6w= X-Google-Smtp-Source: AK7set8Nv9CK41Ey5CQFBMdsQyEjD0aTcPuFbK9Nj5fNuITg4bay7zpfJW2R+AyKSFrEMLueU3dF6Q== X-Received: by 2002:a05:6a20:3d81:b0:be:da1c:df65 with SMTP id s1-20020a056a203d8100b000beda1cdf65mr17246836pzi.28.1677227266073; Fri, 24 Feb 2023 00:27:46 -0800 (PST) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:94b7:9528:e02e:6dc5]) by smtp.gmail.com with ESMTPSA id u1-20020aa78481000000b005a8512c9988sm4598632pfn.93.2023.02.24.00.27.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 00:27:45 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 157021142C8D; Fri, 24 Feb 2023 18:57:43 +1030 (ACDT) Date: Fri, 24 Feb 2023 18:57:43 +1030 From: Alan Modra To: Nick Clifton Cc: binutils@sourceware.org Subject: Re: Commit: Better caching in elf_find_function Message-ID: References: <87bklkths4.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bklkths4.fsf@redhat.com> X-Spam-Status: No, score=-3027.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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