From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta40.uswest2.a.cloudfilter.net (omta40.uswest2.a.cloudfilter.net [35.89.44.39]) by sourceware.org (Postfix) with ESMTPS id BEE123858D1E for ; Fri, 8 Sep 2023 18:56:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BEE123858D1E 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 eig-obgw-5009a.ext.cloudfilter.net ([10.0.29.176]) by cmsmtp with ESMTP id eWCFq98gObK1VegeTqoejS; Fri, 08 Sep 2023 18:56:21 +0000 Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTPS id egeSqULtsnUsoegeTqovNH; Fri, 08 Sep 2023 18:56:21 +0000 X-Authority-Analysis: v=2.4 cv=HdwH8wI8 c=1 sm=1 tr=0 ts=64fb6e55 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=OWjo9vPv0XrRhIrVQ50Ab3nP57M=:19 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=zNV7Rl7Rt7sA:10 a=Qbun_eYptAEA:10 a=CCpqsmhAAAAA:8 a=OAUjs9tYzMAdVLvrjE8A:9 a=ul9cdbp4aOFLsgKbc677: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=lnk6OKOxd9BwlFKSA+iI6OoUjN+HAJUkVfE5HsTCeu0=; b=NJzUfiRG21fIbXylayDGui0DsJ AYmm+zLPj68Bzg6i3R2QhoPMsdYoFa5+pPtMOeU5L1RXGdmUDgoq/vr++jVsI9tJBq4pv92tCW2HI hcBUPXIcV8q30vodOe9X7kKeP; Received: from 71-211-130-31.hlrn.qwest.net ([71.211.130.31]:36744 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 1qegeS-002as1-0y; Fri, 08 Sep 2023 12:56:20 -0600 From: Tom Tromey To: Tom de Vries via Gdb-patches Cc: Tom de Vries Subject: Re: [RFC 0/7] [gdb/symtab, cc-with-dwz] Fix gdb.cp/breakpoint-locs.exp References: <20230825155546.19617-1-tdevries@suse.de> X-Attribution: Tom Date: Fri, 08 Sep 2023 12:56:19 -0600 In-Reply-To: <20230825155546.19617-1-tdevries@suse.de> (Tom de Vries via Gdb-patches's message of "Fri, 25 Aug 2023 17:55:39 +0200") Message-ID: <87edj8lcj0.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: 71.211.130.31 X-Source-L: No X-Exim-ID: 1qegeS-002as1-0y X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 71-211-130-31.hlrn.qwest.net (murgatroyd) [71.211.130.31]:36744 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Org: HG=bhshared;ORG=bluehost; X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfHukz02TX1cK90wPJ8ROiH2GakkwwjLKWVDeJ/Kat1lvWBzjLvRJSuxVdHZphY26Kep+IenSiNJTFkon9IKTt6QXJFVfm2T7G5/Qb7Bh7+sh5QLKp21l JHdvtsMACTSSnVSOIBAu70q4jWX+J/KlQEBZHo21jSIpj6IFsrlkZ0QKulkfT+3babWJ9N/dsOgI5NKETtWaoaaA1ZowlOjmhAo= X-Spam-Status: No, score=-3018.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: >>>>> "Tom" == Tom de Vries via Gdb-patches writes: Tom> Currently resolving deferred entries is done in the parallel for that Tom> computes the cooked index. The last patch moves resolving of deferred entries Tom> out of the parallel for. Tom> We can add two optimizations to move some of that computation back into the Tom> parallel for: Tom> - resolve intra-shard dependencies at the end of generating the shard, and Tom> - don't defer backward intra-shard dependencies. Tom> Both of these require to keep track of the range of DIEs that was indexed Tom> in the shard, because currently the parent tracking cannot distuinguish Tom> between the "no parent" and "don't know" cases. Right now, we let "CUs" race on reading a PU -- whichever thread happens to need a PU first does the reading and the other ones just, IIRC, mark the dependency and move on. But rather than move these data structures into the shards, would it be possible to have all CUs wait for the PU to be read and keep a reference to it? Then the name computation can still be done during scanning. The benefit of this is that it means that only the bad case has to really pay for the overhead. That is, dwz is uncommon and efforts to support it shouldn't penalize normal DWARF reading. Insert a rant here about how DWARF is awful... there is no real reason any of this has to work this way or be so difficult. Tom