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 78B703858D33 for ; Wed, 28 Dec 2022 16:37:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 78B703858D33 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 outbound-ss-761.bluehost.com (outbound-ss-761.bluehost.com [74.220.211.250]) by qproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 8235980350D3 for ; Wed, 28 Dec 2022 16:36:59 +0000 (UTC) Received: from cmgw13.mail.unifiedlayer.com (unknown [10.0.90.128]) by progateway8.mail.pro1.eigbox.com (Postfix) with ESMTP id 2D96A100411E4 for ; Wed, 28 Dec 2022 16:35:37 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id AZOzpuBr3NX2aAZOzpPibd; Wed, 28 Dec 2022 16:35:37 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=NMAQR22g c=1 sm=1 tr=0 ts=63ac7059 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=sHyYjHe8cH0A:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=Zr03i7uNNF_rJkgZhuoA: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=czHvLhPIwG04WOIEwLvxB+jUqG88Oe5SvE49tzm7V18=; b=bdXh8fN38O18Ri8Z+NRb5k8ShW RoeemG4DG02mU6qj+XebMlWT0X8neJBnMZA6S1CC4hIyYfRo5bxQQixsYyl27G4r5Td620pZ64MJz o5cMpdY267qgJ+UhN6Nb7aqIj; Received: from [161.98.8.3] (port=55754 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 1pAZOy-003vx4-OC; Wed, 28 Dec 2022 09:35:36 -0700 From: Tom Tromey To: Eli Zaretskii Cc: Tom Tromey , gdb-patches@sourceware.org, luis.machado@arm.com Subject: Re: Two observations using GDB 13 snapshot References: <83h6xugc5v.fsf@gnu.org> <58b64bf8-90b6-d080-c060-d03761501199@arm.com> <83k02neezy.fsf@gnu.org> <835ye7e9jw.fsf@gnu.org> <87h6xrks77.fsf@tromey.com> <83mt7idacj.fsf@gnu.org> <87fsd4elb2.fsf@tromey.com> <83o7rs4qmg.fsf@gnu.org> <87cz84dasj.fsf@tromey.com> <835ydw20bw.fsf@gnu.org> X-Attribution: Tom Date: Wed, 28 Dec 2022 09:35:33 -0700 In-Reply-To: <835ydw20bw.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 27 Dec 2022 20:00:51 +0200") Message-ID: <87wn6bbi5m.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (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: 161.98.8.3 X-Source-L: No X-Exim-ID: 1pAZOy-003vx4-OC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (prentzel) [161.98.8.3]:55754 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3021.8 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: Eli> And one more thing: this is a native 32-bit Windows build of GDB, so Eli> it has DWARF2 info in PE-COFF file, not in ELF. Maybe this could Eli> explain the difference? Or maybe the C++ code is a factor? The object file format shouldn't make a difference. The DWARF code just reads the appropriate sections (this code hasn't changed since GDB 12) and the actual parsing is independent of the object file format. C++ being used in the executable would possibly explain the difference between reading GDB and reading Emacs, but I don't think it could explain the performance difference between GDB 12 and 13 reading the same executable. I don't have a theory for what could be wrong. Maybe profiling is the best way. It might also be interesting to verify that the parallel_for_each in gdb/dwarf2/read.c is the culprit; that can be done by setting breakpoints before and after it and measuring the time it takes to "cont" from one to the other. The idea of this is that if the new reader is the source of the problem, it would show up here. Tom