From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 13W9ELO/82dNKyoAWB0awg (envelope-from ) for ; Mon, 07 Apr 2025 08:06:11 -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=EX+wCt+u; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 26D551E100; Mon, 7 Apr 2025 08:06:11 -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 03F6F1E05C for ; Mon, 7 Apr 2025 08:06:09 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8BC9E384A48D for ; Mon, 7 Apr 2025 12:06:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8BC9E384A48D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1744027568; bh=TfyEMXbS6ejfvLPS/YI3bpswtXxRs96122mCeQHbyVE=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=EX+wCt+uDGyktg+lhGaqUvWecdQ6PEl9pDMLp+SZb1NseQbNNc9QuRLGr4q6aOnRT SXeCRsvlJfFtEVjum1bym3zeC0w2dgOgJ4XhFkVKeLkkR+I+lhCbHZtmbEl2xRZV2s CLszg7h//zo2dFiWtPdMNHd1FIQ1FOlGPddBlVuE= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 92DD63850430 for ; Mon, 7 Apr 2025 12:05:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 92DD63850430 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 92DD63850430 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1744027517; cv=none; b=vMlI2Z42+2q0vsTq5wmS+FgeeUNzH1FoGQLykiumq3HYZzohT2VqLHiIdsfFAFt9ZLJ/msDEzME/0m6bIxPtpitsJ/UsgHSIl9GT6GgoHvn2QKjslpQgejoeYpjymvHR4D1NuilxLolnkA3Uae4MB673IsXyIAbezpvDdm9s4DU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1744027517; c=relaxed/simple; bh=WFRH3xNxduE3IDPxOzrCL+Ao/4h24hfu9N3okHiqylw=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=wdDQjGyiXpjxWF4DPonIEm1rv82Cn/Jy5wlJnkGmFuq7MzhpDjKaHBxr4Ac1noxX6BcODetzR27v+HVX3iP0fPgJw6oEg/sPbtzcN5olASsRi7QDXk4JiT03Jodt4BAZmP1CQmOeYF+FyQhhWQzKli3SzOpdd1YSHsED4AMyJts= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 92DD63850430 Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-127-LI0gD3aQMpuZr5hIT8Y-JA-1; Mon, 07 Apr 2025 08:05:16 -0400 X-MC-Unique: LI0gD3aQMpuZr5hIT8Y-JA-1 X-Mimecast-MFC-AGG-ID: LI0gD3aQMpuZr5hIT8Y-JA_1744027515 Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-227ed471999so34727825ad.3 for ; Mon, 07 Apr 2025 05:05:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744027515; x=1744632315; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TfyEMXbS6ejfvLPS/YI3bpswtXxRs96122mCeQHbyVE=; b=rRi5clKabaQolHHa9dRJlEvZp6KPQFNG75NWawLFXYJktPFD+/0y/hXysl7y8jnXdw zSFqB9qXwJCvUVq747nh2ZCgVTQ4tI7A5tSc2W105LjHYXEzthO7k02ghKy6tWCl1oJt hLli0BAVx3RL9sIOFEp+QD/mUh65M+FvOq8r8/gGXC85NnosBe26WkdT+KbYcRGOKL0+ Jjj+tnOdRb0IYtziFDx6ex8Xvz0bgTEkNmJ+u+BxQ2v6ypdQsE+l815W8BwVbSzB8JF8 555wqhxGKwY5lV7wrBLlJepl+WftqbMphwt+jPFVjFTCuN9MhnxmhOqjJAT6KZfOvc9x lqIA== X-Forwarded-Encrypted: i=1; AJvYcCU8Dwney2ahxbvzRi7DkQKbA6T33Zssvpm8XOSyo/UGLiMO9WOaRPFxx0bNQsCuKW5ttZ0=@sourceware.org X-Gm-Message-State: AOJu0Yw8Hz8FbxOBo6fXLXqlff+0RUX7+FSc5fUFiCuMpZnnXmAYDHNU S27Yb7fRyGL4AQnBdtkxmG2IwEgZsUz9jQKtMqGCCepxvFyrzwrLoI3+v5R282hGDUBCCrpuAA6 JnMiNd5umclboDsyHvRSCisYUS6ewblNu4SjmzHc7mfJFSH8rj9YgWYpe X-Gm-Gg: ASbGncvoP0kYAC3PQKBzsr8vDmd4MQ7I+M303jVN1YetiSY7PMvqegaelIAZWkrpYbK TQZ06nsyBPqp21o56rCS0gS0udyfmDJoBfeWXgGa0RW9svgKxCcU7OEKbcp9R+fy/QYTzkBfi4z xFnEEiT5HwowPblnv2kz+LaMPhdmtA3/O1SDomCgidbmn0Trtq1UzjTxFJVDPP7Qmm4mF2guQqV RSvvQWAEPiu23dNK2Rnt/CWEJH7wJU/w14iFhI7ybJxp6MQ4R1oD157WUyaGtusY1E64SXvWg78 TzN1R3mmKzktalc5nwKAR7cMTuM= X-Received: by 2002:a17:902:d4cb:b0:227:e980:9190 with SMTP id d9443c01a7336-22a8a0b374fmr191058495ad.44.1744027514812; Mon, 07 Apr 2025 05:05:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFgbf0eujjyb8KawDPIDtJgJlUBPDTpuE7qGsV9QFGGhuh/zVD/QAgY43hythj2MC1ekgxtkw== X-Received: by 2002:a17:902:d4cb:b0:227:e980:9190 with SMTP id d9443c01a7336-22a8a0b374fmr191057985ad.44.1744027514410; Mon, 07 Apr 2025 05:05:14 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:9a69::1001? ([2804:14d:8084:9a69::1001]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2297877288csm79166185ad.232.2025.04.07.05.05.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Apr 2025 05:05:13 -0700 (PDT) Message-ID: <6214910b-519f-420f-8999-b05e5410ad5a@redhat.com> Date: Mon, 7 Apr 2025 09:05:10 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Loading some symbols, when, and index-cache To: =?UTF-8?Q?Llu=C3=ADs_Batlle_i_Rossell?= , gdb@sourceware.org References: In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: XU36K35DT9LxbBeH8srrMYOpOQxCoeqIe5EdFMre4bc_1744027515 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed 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: Guinevere Larsen via Gdb Reply-To: Guinevere Larsen Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 4/6/25 12:07 PM, Lluís Batlle i Rossell via Gdb wrote: > 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? I can't answer all questions, but I can help with two of them:  > is there any way this work can be done ahead? Yes! you can use the --readnow option to force gdb to read all symbols of the added inferior... however  > Why not all CUs have been loaded yet? It is super slow. Your example completion managed to avoid reading half of all symbols and you already felt the time, doing twice that work every time you start up your debug section would be very noticeable for little gain considering that most debug sessions won't span all the codebase. To get a sense of how much of a slowdown that is, I tested locally and: $ time ./gdb gdb --batch -ex "complete list def" #Basically the same as you did ./gdb gdb --batch -ex "complete list def"  42.40s user 1.19s system 120% cpu 36.243 total $ time ./gdb gdb --batch --readnow -ex "complete list def" ./gdb gdb --batch --readnow -ex "complete list def"  58.32s user 1.79s system 100% cpu 1:00.08 total So even with the slower expansion, GDB is still faster than if we had all symbols being read at the start, and this isn't even taking into account the memory usage. I can't help with the cache stuff, though, never touched it. -- Cheers, Guinevere Larsen She/Her/Hers > > Regards, > Lluís. >