From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id JY0GMDDBxGj5IQIAWB0awg (envelope-from ) for ; Fri, 12 Sep 2025 20:56:16 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=KVb9vsuQ; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id AD0661E0BA; Fri, 12 Sep 2025 20:56:16 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no 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 171E31E047 for ; Fri, 12 Sep 2025 20:56:16 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 83FEB3857B91 for ; Sat, 13 Sep 2025 00:56:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 83FEB3857B91 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=KVb9vsuQ Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 6CC203857C4F for ; Sat, 13 Sep 2025 00:55:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6CC203857C4F Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6CC203857C4F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1757724935; cv=none; b=vsjqAFSBBS/6e3yPIJk0CgDfXSb+GJMdKVNIFxPo7bKmU8CffXZkhTtcuBf7sGW9tP0nUEc6juXpji+kPdcGsiaNO3jBSSXyDBuDqoc0EuLwPUNKJ/rt/gliTGGsk5KCAOm9W5Smaxclrg/nXZcX8ZEa+8DsnhwMXrpNdGSuRPY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1757724935; c=relaxed/simple; bh=ltxdqNTyyktbZVezbdP3o/ZnpiLVGkwJj2VZHAi10qA=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=IMVwQy/q0lKmxfc+61OjF6bFg2N8Ye46wPOg+EsguGxMrlDQ1xHx9VIHQPLp3zfnDjMpfthikgovHgybCykWxK1OTNXi5/ilqQCBaHBns/tr5mcdXf3IM7mLXmJU2D1l87wc9gZ+Whg4DKQ4gKnYjuqRHCoBamN6//nvgAAtwYc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6CC203857C4F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1757724935; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4Ti+dGPxoBe6dmMCoIfXJLOV2BsuJKWLOvy0sGs2KKg=; b=KVb9vsuQFd5U2IEsl7PkNFu/Vq2n0hxcCJgmYqAswfD8f4+q9+0HTlk08WJVgr2T9NfIcI hN85e8IS47tym/fazs8dLhZ0yCH9GEbJlN1STqOSU04nlaREvw+0GWa9cfAugsxf9esa01 hmOPSPXSbd7kTxqFhXXzkEf9n5VryqI= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-112-QTZZoYVHPZC3Mf4tGFHnvw-1; Fri, 12 Sep 2025 20:55:31 -0400 X-MC-Unique: QTZZoYVHPZC3Mf4tGFHnvw-1 X-Mimecast-MFC-AGG-ID: QTZZoYVHPZC3Mf4tGFHnvw_1757724931 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D09831800447; Sat, 13 Sep 2025 00:55:30 +0000 (UTC) Received: from f41-zbm-amd (unknown [10.22.80.10]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id E31AF1800447; Sat, 13 Sep 2025 00:55:29 +0000 (UTC) Date: Fri, 12 Sep 2025 17:55:23 -0700 From: Kevin Buettner To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: Re: [PATCH v2] gdb/dwarf2: Add symbols for function declarations Message-ID: <20250912175523.74dca8b4@f41-zbm-amd> In-Reply-To: <875xdwsye2.fsf@tromey.com> References: <20250703194719.2254338-1-kevinb@redhat.com> <875xdwsye2.fsf@tromey.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: _8o8r530R0-cqVtiuvxF7imlVbrFxTLnMZ_ksNlJZhQ_1757724931 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On Fri, 05 Sep 2025 09:38:13 -0600 Tom Tromey wrote: > >>>>> "Kevin" == Kevin Buettner writes: > > Kevin> This version 2 commit > Kevin> adds that by making DW_TAG_subprogram declarations "interesting" to > Kevin> the indexer. The changes which do this are in gdb/dwarf2/abbrev.c > Kevin> and gdb/dwarf2/cooked-indexer.c. > > I have some questions about this change. > > How many symbols does it add, and what performance impact does it have? > I tend to think the indexer is fast primarily because it skips DIEs, but > IIUC this will have it read many more. > > Do these declaration symbols end up in .debug_names and .gdb_index? I > suspect they should not. (Particularly for .debug_names which > specifically excludes them in the text of the standard.) > > Does "break" on such a symbol result in many more CU expansions? If so > then I think this is a problem, because a declaration by its nature is > not useful for breakpoints. I'm still gathering data and I'm trying to make sense of some of the data already gathered, so I'm not quite ready to dive into too many details yet. However, using Simon's methodology, I've tested on 4 different x86_64 machines. On those machines, the total wall clock time increased from between 6.9 to 9.2 percent, depending on machine. However, on my (aarch64) macbook, the wall clock time increased by 267% !! I need to understand why the macbook took so much longer... This patch is of most value when library symbols are unavailable. So it may make sense for there to be a setting to enable or disable loading of declarations. An "auto" mode could, perhaps, cause loading of declarations to be disabled when loading system libraries, but be enabled for user libraries and the executable. And, even for the latter category, GDB could check to see if (say) the C library has symbols. If it does, then it could be disabled. > What does "print malloc" say with this patch in place? Without my patch: (gdb) p malloc $1 = {} 0x7ffff7d2fb10 With my patch: (gdb) p malloc $1 = {void *(unsigned long)} 0x7ffff7d2fb10 These were both run on the same machine, which does not have glibc debuginfo installed, nor was debuginfod allowed to provide any symbols.