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.133.124]) by sourceware.org (Postfix) with ESMTPS id CBA753858405 for ; Wed, 23 Mar 2022 11:47:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CBA753858405 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-74-lAkt2IU0Nse4y5Gz32wJ-w-1; Wed, 23 Mar 2022 07:47:28 -0400 X-MC-Unique: lAkt2IU0Nse4y5Gz32wJ-w-1 Received: by mail-wm1-f69.google.com with SMTP id l1-20020a1c2501000000b00389c7b9254cso1998324wml.1 for ; Wed, 23 Mar 2022 04:47:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=yEO+ZoEnXFti9Cc3vL/U94ayIQeE2Z2o8vtqtnpM1mI=; b=1FcR6ILyzPM9Hz6p8Q1onkByRAUdx39pspGurGNz3QmHbAOqGuHK0UN6UAKBO8Akxo fKw7SRIdb5Qfb1DUjCch1L/xAwqiLbB692nRrggSuEK18Lo/75EH3W5GHLgsJs7LyyMa b2yGb7Nw1IGrUQmU8wRYS0CMXGtEaH3DWkrIFE9Yqe03gXAAVYKFDDTHQyQmKvRLIEP/ PA+dGh0aQI1iZ8i1I1M8UqCHt2HRp+t2mOR0d1FhC2fEscQffwp0kpRZWNeM483K08aQ oJxzcBmhBhZkrvy958LFn34RvnkKYjQWj4ADQ7WF8ysAxmZu2j4ftuPXAstq3h2RBe93 ohUQ== X-Gm-Message-State: AOAM532bQICBK6DCF9jOyuHFQpDJ74ko9oR24MTxS4aGJk99sBsETxZy wzIs2WkpDSMtyl7hnsf3UY0mSKrUaDbRsguGrEXigdAjKRK0XrPg07wZMA4O4kYuziOOf/bsFq0 gAVbEy3FvgznCqk4T7A== X-Received: by 2002:a05:600c:3482:b0:38c:40:9b30 with SMTP id a2-20020a05600c348200b0038c00409b30mr8921894wmq.68.1648036047250; Wed, 23 Mar 2022 04:47:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxx6rLACXkj2ZqAQOoYKdgbQ2G8E26Bv1o9UvSahOLTSmBfZR3ia+OJPPp79zzZZn4/fTrrMw== X-Received: by 2002:a05:600c:3482:b0:38c:40:9b30 with SMTP id a2-20020a05600c348200b0038c00409b30mr8921878wmq.68.1648036047102; Wed, 23 Mar 2022 04:47:27 -0700 (PDT) Received: from [192.168.1.6] (adsl-2-solo-173-39.claranet.co.uk. [80.168.173.39]) by smtp.gmail.com with ESMTPSA id l12-20020a056000022c00b00203ee262d12sm14270702wrz.116.2022.03.23.04.47.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Mar 2022 04:47:26 -0700 (PDT) Message-ID: <0b1da406-5d99-640f-a203-0e17eb72a60e@redhat.com> Date: Wed, 23 Mar 2022 11:47:25 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 To: "Steinar H. Gunderson" Cc: binutils@sourceware.org, sesse@chromium.org References: <20220321124333.1282079-1-sesse@google.com> From: Nick Clifton Subject: Re: [PATCH] Fix return code in _bfd_dwarf2_find_nearest_line(). In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.9 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_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2022 11:47:32 -0000 Hi Steinar, > I looked into trying to making a faster structure, probably reusing the > trie from the other patch I posted (ie., making a separate trie that > maps address-to-symbol instead addition-to-compilation-unit), but it > seems the API is that the client has to send in the list of symbols it > wants to use for fallback? I do not think that it is for fallback, but rather that it is expected that all callers of this function will have already decided upon the symbol table that they want to use, and so it is provided as a parameter. (A single binary file can have multiple symbol tables, so there needs to be some way to select which one to use. Making the caller perform this choice is the easiest solution). Is that right; so we cannot really create a > persistent structure? (The find_nearest_line function is marked as not > documented yet, so it's not all that easy to know what the intended API > is :-) ) You probably could make a persistent structure. It is unlikely that the code will called with different symbol tables under most use cases. But you would need to detect if this has happened and ditch/refresh your storage in that case. Cheers Nick