From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qproxy6-pub.mail.unifiedlayer.com (qproxy6-pub.mail.unifiedlayer.com [69.89.23.12]) by sourceware.org (Postfix) with ESMTPS id 59A4F3858D32 for ; Sat, 18 Feb 2023 01:43:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 59A4F3858D32 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 gproxy1-pub.mail.unifiedlayer.com (unknown [69.89.25.95]) by qproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 7A4FD8028E17 for ; Sat, 18 Feb 2023 01:43:15 +0000 (UTC) Received: from cmgw14.mail.unifiedlayer.com (unknown [10.0.90.129]) by progateway3.mail.pro1.eigbox.com (Postfix) with ESMTP id 6BDA41004811F for ; Sat, 18 Feb 2023 01:42:15 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id TCExpw7WSBkq3TCExp66KT; Sat, 18 Feb 2023 01:42:15 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=DdHSFthW c=1 sm=1 tr=0 ts=63f02cf7 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=m04uMKEZRckA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=20KFwNOVAAAA:8 a=7LgPv9MApWzp8lTH5hUA:9 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=a3pRgUMPRHP0+2u2VfegpRbL+b3Y5NG9z3GpfNYEYWI=; b=X4YTSLVPflH+aFhaHILrO96PcL uSKFWvnAN9jaL8JPG4ZVUOmNAjE0rJT7Ek5s85dzmchqnxsdxzyoEYF/qZW2sEc3rBibznVs5HBlE aKHMdy8wovOWFGUKe+0jn43m6; Received: from [172.58.62.131] (port=9779 helo=prentzel) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pTCEv-003pHr-NW; Fri, 17 Feb 2023 18:42:14 -0700 From: Tom Tromey To: Andrew Burgess Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH] Fix "start" for D, Rust, etc References: <20230214030000.1982722-1-tom@tromey.com> <87k00gkjx1.fsf@redhat.com> X-Attribution: Tom Date: Fri, 17 Feb 2023 18:42:08 -0700 In-Reply-To: <87k00gkjx1.fsf@redhat.com> (Andrew Burgess's message of "Fri, 17 Feb 2023 22:26:50 +0000") Message-ID: <87ilfz92bz.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: 172.58.62.131 X-Source-L: No X-Exim-ID: 1pTCEv-003pHr-NW X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (prentzel) [172.58.62.131]:9779 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3019.9 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 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: >>>>> "Andrew" == Andrew Burgess writes: >> A long time ago, in an earlier threading attempt, I changed the global >> current_language to be a function (hidden behind a macro) to let us >> attempt lazily computing the current language. Perhaps this approach >> could still be made to work. However, that also seemed rather tricky, >> more so than this patch. Andrew> ... I don't understand what this last paragraph has to do with the Andrew> problem being solved here. Yeah, it's kind of tangential. Essay follows. In an ideal world, gdb would scan the DWARF, and if it saw DW_AT_main_subprogram, it would use that name. That doesn't fully work because gdb requires canonicalization. (Maybe all debuggers do in some way or another, but gdb chooses to do it during scanning, so it affects the user-visible startup time.) gdb makes a second choice here, which is to use the "main" to set the initial language and context. So, if gdb scans the DWARF and waits for canonicalization in order to use "main", then users will wait the entire time it takes... whereas right now, we hide some of this by canonicalizing in a worker thread. This patch preserves this feature by deciding to only handle a subset of languages. Another possibility would be to delay the search for "main". When the user runs "gdb program" and the prompt appears, there's no real need to pre-emptively find "main". Instead, it can be deferred until the first command that actually requires it. That's what this earlier patch did. IIRC, I added a "#define" for current_language that would compute it when first needed. I think this required some hacks as well (at the time I think Python initialization wanted the language). Another possible approach here would be to canonicalize just the "main" entry and its parent entries when needed. This is some annoying bookkeeping but maybe not too bad. It's worth noting, though, that elsewhere I'm working on patches to move more of the DWARF reader into worker threads. There, the idea is to start the DWARF reader immediately in dwarf2_has_info (in the background). If we had lazy current_language setting, this work would make the user experience even faster startup times (sometimes). With the current shape of the patches, the difference is small for the "file" case (it's more aimed at "attach"), because, once again, gdb has to wait for the DWARF reader to dig up that DW_AT_main_subprogram. Speeding up DWARF reading is pretty hard. Partly this is because DWARF is bad, but partly it's due to choices gdb makes. However, since it's regularly the slowest thing users encounter, IMO it's worth the extra effort both to try to hide the costs, and also to try to think of alternative solutions that perform well. Andrew> I have a couple of _really_ minor comment fixes that I think would help, Andrew> and one small code suggestion. See inline below. I'll fix all these up. >> cu {} { >> + # Note we don't want C here as that requires canonicalization. >> DW_TAG_compile_unit { >> - {DW_AT_language @DW_LANG_C} >> + {DW_AT_language @DW_LANG_PLI} Andrew> I'm curious why PLI? I guess it's to force GDB to select language Andrew> minimal, but this is so weird it feels like it's worth a comment. There's the "don't want C" comment but I will expand it. Anyway I chose a language that gdb is unlikely to support and also that made me laugh. Normally of course this would be COBOL, but a GCC front end for COBOL is going in so... Thanks for the review. Tom