From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 6AA913857365 for ; Fri, 24 Feb 2023 12:25:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6AA913857365 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677241534; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qI6IPV7Fv9rLkhdNjXfJaTsIdv4n2ZYehM1AEn/ptnY=; b=Z2bZPkXPCaLieJvawbaLfRhzFkDM9B4FpJEfnxsvrWz4v1Qc3k0039yJvRtYdsockgwn5x PHHdDA7eSbJsxnWppEX/fd4a+h2jflMOZ5ZzVeDdAb3V5TZmSrlwAMsscR6Ea7xg7pce3Y B0iivfDOVDqHkK9dsdEq5wVApXZ5lgQ= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-199-Y2J7GvPlO5abLQOCjymgDA-1; Fri, 24 Feb 2023 07:25:32 -0500 X-MC-Unique: Y2J7GvPlO5abLQOCjymgDA-1 Received: by mail-wm1-f71.google.com with SMTP id s18-20020a7bc392000000b003deaf780ab6so898987wmj.4 for ; Fri, 24 Feb 2023 04:25:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=qI6IPV7Fv9rLkhdNjXfJaTsIdv4n2ZYehM1AEn/ptnY=; b=0SkmulWBXk7kmQZpIkuexmgNNS3HF5WLQ7lTiEq0wK3eDr3u/tMBN9bwlReGqIU6ip sRXnBF8Gf0FnRFFV6nn8i09r6kZROOzPtp5DhyI3Y2r+xInEJLeZgG5q9cNwX/Hs59zp qJ5Olx1rtUp9dajtxHjiAF0KyfaRGN2LDnxImugR186cLwlYObW8Id5uj9dlgXm9LW/b 1b6Pzj1ao2hCSvBUk9FPmrwFnQ1VLfku/JdZ4knuVn6SQIkczBKpOklehc/8ul4eVj3M lmCqzgaUFfkBLAqVY3rGR4ovNeMuJTy9jq76CZ7BuuNgULOx7xihk9rQlkNs9LDPwUfO ScFA== X-Gm-Message-State: AO0yUKWD9FMkpC2+8oaI9s1zisMDcXN2SHDcuO7nsDll2d5sIZWDSP3d ePmUgJO7CsKA2DPjb6YnXr63p5XAjGolluhA6B7A1fclrGn1C8R45wlO7nhx01vFHJBnHXwZFLl jH6m1JMvdNaKg2kqoP05vNxw= X-Received: by 2002:a05:6000:98c:b0:2c5:5ee9:6b27 with SMTP id by12-20020a056000098c00b002c55ee96b27mr12525368wrb.13.1677241530952; Fri, 24 Feb 2023 04:25:30 -0800 (PST) X-Google-Smtp-Source: AK7set/IEXykk9sZfIpfpHx3kTj00Rdcro+fnVDchcCOxInIYFPCh6yK671xLKY+JAeuXZwkFZHU/A== X-Received: by 2002:a05:6000:98c:b0:2c5:5ee9:6b27 with SMTP id by12-20020a056000098c00b002c55ee96b27mr12525361wrb.13.1677241530646; Fri, 24 Feb 2023 04:25:30 -0800 (PST) Received: from [192.168.1.18] ([79.123.86.193]) by smtp.gmail.com with ESMTPSA id z7-20020adfec87000000b002c7163660a9sm3496128wrn.105.2023.02.24.04.25.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Feb 2023 04:25:30 -0800 (PST) Message-ID: Date: Fri, 24 Feb 2023 12:25:29 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: Commit: Better caching in elf_find_function To: Alan Modra Cc: binutils@sourceware.org References: <87bklkths4.fsf@redhat.com> From: Nick Clifton In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="------------Qj527G62bC6HRo0t5MzmFWyb" Content-Language: en-GB X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: This is a multi-part message in MIME format. --------------Qj527G62bC6HRo0t5MzmFWyb Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Alan, > Failures are seen on mips targets. > > mipsel-linux-gnu +FAIL: MIPS PIC relocation 6 (MIPS16) *sigh* I had noticed these, but thought that they were due to an unrelated problem. :-( > 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. Agreed. I am checking in the attached patch to address this problem. It prefers function symbols over non-function symbols and typed symbols over notype symbols. I was not sure if we should prefer LOCAL symbols over GLOBALS so I did not add code for that. Cheers Nick --------------Qj527G62bC6HRo0t5MzmFWyb Content-Type: application/x-troff-man; name="elf-find-function.patch.2" Content-Disposition: attachment; filename="elf-find-function.patch.2" Content-Transfer-Encoding: 7bit diff --git a/bfd/dwarf2.c b/bfd/dwarf2.c index ac7c4f63c57..15862dc2037 100644 --- a/bfd/dwarf2.c +++ b/bfd/dwarf2.c @@ -6146,12 +6146,13 @@ typedef struct elf_find_function_cache } elf_find_function_cache; -/* Returns TRUE if the symbol with address CODE_OFF and size CODE_SIZE +/* Returns TRUE if symbol SYM with address CODE_OFF and size CODE_SIZE is a better fit to match OFFSET than whatever is currenly stored in CACHE. */ static inline bool better_fit (elf_find_function_cache * cache, + asymbol * sym, bfd_vma code_off, bfd_size_type code_size, bfd_vma offset) @@ -6169,24 +6170,45 @@ better_fit (elf_find_function_cache * cache, if (code_off > cache->code_off) return true; + /* assert (code_off == cache->code_off); */ + /* If our current best fit does not actually reach the desired offset... */ if (cache->code_off + cache->code_size <= offset) - { - /* Then return whichever candidate covers more area. */ - return code_size > cache->code_size; - } + /* ... then return whichever candidate covers + more area and hence gets closer to OFFSET. */ + return code_size > cache->code_size; - /* If the new symbol also covers the desired offset... */ - if (code_off + code_size > offset) - { - /* Then choose whichever is smaller. */ - /* FIXME: Maybe prefer LOCAL over GLOBAL or something else here ? */ - return code_size < cache->code_size; - } + /* The current cache'd symbol covers OFFSET. */ - /* Otherwise the cached symbol is better. */ - return false; + /* If the new symbol does not cover the desired offset then skip it. */ + if (code_off + code_size <= offset) + return false; + + /* Both symbols cover OFFSET. */ + + /* Prefer functions over non-functions. */ + flagword cache_flags = cache->func->flags; + flagword sym_flags = sym->flags; + + if ((cache_flags & BSF_FUNCTION) && ((sym_flags & BSF_FUNCTION) == 0)) + return false; + if ((sym_flags & BSF_FUNCTION) && ((cache_flags & BSF_FUNCTION) == 0)) + return true; + + /* FIXME: Should we choose LOCAL over GLOBAL ? */ + + /* Prefer typed symbols over notyped. */ + int cache_type = ELF_ST_TYPE (((elf_symbol_type *) cache->func)->internal_elf_sym.st_info); + int sym_type = ELF_ST_TYPE (((elf_symbol_type *) sym)->internal_elf_sym.st_info); + + if (cache_type == STT_NOTYPE && sym_type != STT_NOTYPE) + return true; + if (cache_type != STT_NOTYPE && sym_type == STT_NOTYPE) + return false; + + /* Otherwise choose whichever symbol covers a smaller area. */ + return code_size < cache->code_size; } /* Find the function to a particular section and offset, @@ -6264,7 +6286,7 @@ _bfd_elf_find_function (bfd *abfd, if (size == 0) continue; - if (better_fit (cache, code_off, size, offset)) + if (better_fit (cache, sym, code_off, size, offset)) { cache->func = sym; cache->code_size = size; --------------Qj527G62bC6HRo0t5MzmFWyb--