From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outbound-ss-820.bluehost.com (outbound-ss-820.bluehost.com [69.89.24.241]) by sourceware.org (Postfix) with ESMTPS id 2B02E3857351 for ; Wed, 26 Jul 2023 16:20:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2B02E3857351 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from cmgw14.mail.unifiedlayer.com (unknown [10.0.90.129]) by progateway2.mail.pro1.eigbox.com (Postfix) with ESMTP id 2FE8F1004CD3F for ; Wed, 26 Jul 2023 16:20:19 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id OhFLqcLcLjnQ1OhFLqPldb; Wed, 26 Jul 2023 16:20:19 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=dLtjJMVb c=1 sm=1 tr=0 ts=64c147c3 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=OWjo9vPv0XrRhIrVQ50Ab3nP57M=:19 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=5GTQWnfxQyi8a9uf:21 a=ws7JD89P4LkA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=CCpqsmhAAAAA:8 a=Wh4jVfKX03REotbumioA:9 a=ul9cdbp4aOFLsgKbc677:22 a=e78j1R5tVTzcXxiiL6ve:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YkvAi0nLzVmQOlqReyh/hCTnO3pjWd9Zc2T9jTMzFZs=; b=VGyakGpx/S0jpLC2Xi+bZS1G4o i1wwvFBXnCKu7z2rIadxOHL2WPlPxjPLvDYs+OMa+dvq8c62IXe4gJCX9+ztC3y98Ous4N8xy7XSf Bm8Vep6BdS0eVIm9VOZhMOTwZ; Received: from 75-166-135-140.hlrn.qwest.net ([75.166.135.140]:49472 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qOhFK-001qzV-2c; Wed, 26 Jul 2023 10:20:18 -0600 From: Tom Tromey To: Dmitry Neverov via Gdb Cc: Dmitry Neverov Subject: Re: Index files are not used in the session where they were created References: X-Attribution: Tom Date: Wed, 26 Jul 2023 10:20:18 -0600 In-Reply-To: (Dmitry Neverov via Gdb's message of "Tue, 25 Jul 2023 10:01:49 +0200") Message-ID: <87351ak5kt.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.135.140 X-Source-L: No X-Exim-ID: 1qOhFK-001qzV-2c X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-135-140.hlrn.qwest.net (murgatroyd) [75.166.135.140]:49472 X-Source-Auth: tom+tromey.com X-Email-Count: 5 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3019.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: >>>>> "Dmitry" == Dmitry Neverov via Gdb writes: Dmitry> I'm investigating whether index-caches help with slow symbols Dmitry> loading (https://sourceware.org/bugzilla/show_bug.cgi?id=30520). ... Dmitry> If I then try loading children of a variable causing a slow symbol Dmitry> lookup, the lookup is still slow. Even though the index is ready Dmitry> and is saved to disk. Dmitry> If I restart gdb after the index is written, then gdb picks it Dmitry> up, and symbol loading is much faster - a few seconds instead of Dmitry> a minute. Dmitry> Is there a way to use the created index without gdb restart? Actually I'm surprised to hear that the index makes a difference in this case. It would be good to understand this better -- maybe there's a bug. The reason I say that is that gdb has a "two phase" DWARF reader. The first phase scans the DWARF, building a symbol table. In the index case, this just means mapping in the index (and maybe doing a bit of processing). Currently, gdb will pause until this phase is complete. That is, if you run "gdb -nx" and use "file some-executable", the prompt won't return until scanning is done. After this is what is called "full CU expansion". If you print a variable or set a breakpoint (or otherwise cause gdb to need debug info), gdb will re-read the DWARF for selected compilation units, expanding the ones it thinks are necessary. This phase only has a single implementation -- it does not depend on how the scanning was done. This is why it's surprising that the index would make a difference here. That said, the two scanners might differ on how they select which CUs to expand. I'd guess that is what you are seeing. Maybe it means that the index is failing in some situation -- or maybe it means we could make the DWARF scanner implementation a bit faster by having it expand less. To figure this out, we'd probably need a test case. Maybe comparing the results between the two scenarios with "set debug symtab-create on" would indicate something. Tom