From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by sourceware.org (Postfix) with ESMTPS id E71453858C2C for ; Fri, 25 Mar 2022 00:01:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E71453858C2C Received: by mail-wm1-x329.google.com with SMTP id p26-20020a05600c1d9a00b0038ccbff1951so2101151wms.1 for ; Thu, 24 Mar 2022 17:01:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=BjXCEQ8w6ZiP4rYJniAs9QJSA6cwzWKQ21OClEeRlYE=; b=rK6ogToZTqPK9GU1NJVm9KfUEqMdWeLHxSHsF6WIPfkpIBAhpIB6N7pvCdDHc2Dzx2 12XUn5KOQpDn8MBXz9WYURJ/VyTfVL91t/ruFDxxe1oC/v4DKAISN6MZPe/Fj55lv7j7 jpGuZjwvSRH7+7W1vErdiIR1AIWB6AEIdBzGngAlCGQup0P0hMV0pfLeULFOgYsmkeCA EmKtIwTbD0g+XfsmjOiir1oL2kdHuxsgUhjrb0HuPPSQ4/D6m4UbAMhZb7BBoZFU1M5N KfedkPMpYxBCWwYRRig4q07vr/qrSYzfqaurNH0sCw5n4pmFS5CVTx+tno2XQXeQJ3MY SEdQ== X-Gm-Message-State: AOAM530pWsdSfvGeL1J6RYTeZyuSGMN1CppGEMrxShtDKomAcXaNewhK r3P/UgUWTG1B7fVBtU+8EtrGsg== X-Google-Smtp-Source: ABdhPJx1JpuvLmmXMSKY+2vAn8SkeXtRqE1/W93v7F9Ir7CVD8qjznoCQEFI4XrDzriyvXl1JaRbcw== X-Received: by 2002:a7b:c041:0:b0:38c:7c21:8ade with SMTP id u1-20020a7bc041000000b0038c7c218ademr16499045wmc.163.1648166479532; Thu, 24 Mar 2022 17:01:19 -0700 (PDT) Received: from google.com (110.121.148.146.bc.googleusercontent.com. [146.148.121.110]) by smtp.gmail.com with ESMTPSA id a12-20020a5d53cc000000b00205a0ee9c74sm808961wrw.89.2022.03.24.17.01.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Mar 2022 17:01:17 -0700 (PDT) Date: Fri, 25 Mar 2022 01:01:14 +0100 From: "Steinar H. Gunderson" To: Alan Modra Cc: Nick Clifton , binutils@sourceware.org, sesse@chromium.org Subject: Re: [PATCH] Add a trie to map quickly from address range to compilation unit. Message-ID: References: <20220321094030.1256430-1-sesse@google.com> <63191455-2374-5db9-f55e-ddf794c7d88e@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-18.9 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL 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: Fri, 25 Mar 2022 00:01:23 -0000 On Fri, Mar 25, 2022 at 10:00:29AM +1030, Alan Modra wrote: > This would be reverting commit 240d6706c6a2. In > https://sourceware.org/bugzilla/show_bug.cgi?id=15935#c3 I came to the > conclusion that the pr15935 testcase had bogus debug info and closed > the bug as invalid. The reporter apparently opened another bug, > https://sourceware.org/bugzilla/show_bug.cgi?id=15994 a month later > that Nick fixed by making _bfd_dwarf2_find_nearest_line do extra work. > Which of course is unnecessary with good debug info, but in many cases > we try to make binutils give the best result even with bad input. I > don't know the details beyond that. It might have been that the > compiler producing the bad debug info was one supported by RedHat. Thanks for going through the history here. Note that my patch changes the equation somewhat; as long as the debug info has been parsed for the CU (I understand that this is done somewhat incrementally?), the cost of looking through all CUs instead of stopping at the first one is nearly zero. Generally, we pay a cost proportional to the number of ranges that overlap with the given 256-byte region which should be very pretty few in a well-behaved binary, and not a lot even in a really bad one. (Well, that's not strictly true; if the number of such ranges is fewer than 8, we could be testing up to 8 ranges. But it's still cheap.) But of course, if we want to keep parsing debug info from new CUs, that has a definite cost. But that cost is per-CU, not per lookup, so if you're looking up lots of addresses, it's “only” startup cost. Whether this matters depends on the use case, of course. In any case, I think the decision here should be more clearly communicated in the source :-) The existing comment saying that we keep looking is very useful, but the decision to _not_ keep looking into not-yet-parsed CUs (in some cases only!) is less clearly articulated. /* Steinar */