From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id lGAzAuOY8mc8GykAWB0awg (envelope-from ) for ; Sun, 06 Apr 2025 11:08:19 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=P84Rqwsb; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id DEDA21E0C3; Sun, 6 Apr 2025 11:08:18 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 1A3F61E05C for ; Sun, 6 Apr 2025 11:08:18 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 97B10384A810 for ; Sun, 6 Apr 2025 15:08:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 97B10384A810 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1743952097; bh=BPUawH/8kxNr72J1JPJDOEHcNl36vMdCuEeKu5Ux2qc=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=P84RqwsbCOBVTGgzN42g1XCajZYwSOuh9bh8d8OW5f0BJG/cM8foXECeCyxkKewnS 4PQBnEZDDw9+YXxdw2/CWM/iKQZbfcxahbTvC9ec/vQt0Fk3tzNiI54GuMPFgusSMB WRoD3rZ1a0+xScmzGFS5IT7oQgUAwhWofOLVZu0I= Received: from mail.viric.name (mail.viric.name [37.18.133.75]) by sourceware.org (Postfix) with ESMTPS id 1A73C384A868 for ; Sun, 6 Apr 2025 15:07:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1A73C384A868 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1A73C384A868 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1743952059; cv=none; b=grKm+3BDtRI/KCFhCoX3Ox3ZEIa317TwY14Duizx24H+vqLFpGxDy4vj+A/R2hoMKTRMyfBpbdJKnCZKZI2b+rUrG56JMHy8PSJS2mKfMxQ3kghX/45+pdct2dPBADOx/Jq/WxgjGNsWTM/xaVdVVGAUYRz9MMoiUSMJ5j1mSLg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1743952059; c=relaxed/simple; bh=LScFsidxS3sDOIzggTVzRc2wWPXvmmXmbQLrI0gSOcI=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=WUyZSSWVnOHbEejJutrqkmXHJt6vcEEV8hCtyBPr5IIhrZYIxtpWmFdWqioRVzPWhLqhHpU2bakCyKONtFM2Gv+2hoXwkkKL6YSUA5E8qm6SXa8Ghe6WUCXgfWAw5sgxabqYheqXO7o/bqS/o37trPO74LzOi9sEzTn3VBmbzBA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1A73C384A868 Received: by mail.viric.name (Postfix, from userid 1000) id 1928A1A8C96C; Sun, 06 Apr 2025 17:07:38 +0200 (CEST) Date: Sun, 6 Apr 2025 17:07:37 +0200 To: gdb@sourceware.org Subject: Loading some symbols, when, and index-cache Message-ID: X-Accept-Language: ca, es, eo, ru, en, jbo, tokipona MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: =?utf-8?q?Llu=C3=ADs_Batlle_i_Rossell_via_Gdb?= Reply-To: =?utf-8?B?TGx1w61z?= Batlle i Rossell Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" Hello, I'm trying to make sense of what symbols are loaded and when, in gdb. For example, opening an elf file, it will build some index (usable as index-cache) of some symbols, but not all. If I do "gdb gdb" (for my compiled gdb), and then "maint print stat" I get: Number of "minimal" symbols read: 33435 Number of read CUs: 0 Number of unread CUs: 682 Why haven't all CUs been read, and incorporated into the index? Because at file loading the CUs symbols index is generated with worker threads (read.c), therefore, potentially using all cores of the system. And the result would be cached in the index-cache. Because the next thing I notice is that when I type "list def" to get symbol completion, a very slow single-thread symbol expansion causes many CUs to be loaded. After which:, "maint print stat": Number of "minimal" symbols read: 33435 Number of "full" symbols read: 2732412 Number of "types" defined: 4292812 Number of symbol tables: 57075 Number of symbol tables with line tables: 9608 Number of symbol tables with blockvectors: 351 Number of read CUs: 351 Number of unread CUs: 331 Is there any way this work can be done ahead? Why the index-cache only helps for the "minimal" symbols? How can we use the cache for all symbols? Why not all CUs have been loaded yet? Regards, Lluís.