From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta36.uswest2.a.cloudfilter.net (omta36.uswest2.a.cloudfilter.net [35.89.44.35]) by sourceware.org (Postfix) with ESMTPS id E82FE3858D3C for ; Mon, 29 Apr 2024 20:04:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E82FE3858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E82FE3858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=35.89.44.35 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714421100; cv=none; b=WXD9kzcJgjztk/DyLJMsOA6kKbQxF2bdtiy4+G49S9oY2CD01MmdNWxKfUrmq1YSQ8Fqew/lmVAfbIl8QrQomvbpUNPTtGXYQMEeaHha9JLabG+OQP1azyo3Ap04Zom01Z2I+oQVDrZikqYr1YnGxw157tCyWzvIyXc6lJ/WU7U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714421100; c=relaxed/simple; bh=m/QRPoct76nvXYqk69fwuGiYuqmQaB+i8JvA7glug5Q=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=GtYkaWs9C87E1w/2Ox3I2NP7pLnFH5XvxL/+1Qz+EC/ol0DPPGnOh1HMNROo+tAwcMnaDuvYpANXX42GZgVoB87bT6CZ1YZawh3H+zYRSpmidxeecCP0XyatPZ/fpxjLJm6TbWXyhABM+5Vdjg+3s+PDXlftlBfsLaCjvxdiuiA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from eig-obgw-5009a.ext.cloudfilter.net ([10.0.29.176]) by cmsmtp with ESMTPS id 1TqOsu3p7JXoq1XF6suIzw; Mon, 29 Apr 2024 20:04:52 +0000 Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTPS id 1XF5silYxELAW1XF6sldMB; Mon, 29 Apr 2024 20:04:52 +0000 X-Authority-Analysis: v=2.4 cv=EfzOQumC c=1 sm=1 tr=0 ts=662ffd64 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=raytVjVEu-sA:10 a=Qbun_eYptAEA:10 a=20KFwNOVAAAA:8 a=mEJjf13d8PtDLcr8fbsA: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:Date:References:In-Reply-To :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=o+6WRExk0Xp+zaug6gvBzNLvBwx1tpDinXIjUV4irIs=; b=iBElJE+0uK57WXpz39FDFwDU8Y eSpevZLI5Sh7uVLMfYAHZjS5mqvqb2UPOEULcqyz97Kdx1YwknWmPpObkZgWMOzQTO8iR2O/wiWEz ivp8PbVIBFGhR7Ji2Oewcfg1p; Received: from 97-122-86-252.hlrn.qwest.net ([97.122.86.252]:38562 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1s1XF5-00166O-1Y; Mon, 29 Apr 2024 14:04:51 -0600 From: Tom Tromey To: Andrew Burgess Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH 1/5] Remove call to dwarf2_per_objfile::adjust from ranges readers In-Reply-To: <87cyq8pbnp.fsf@redhat.com> (Andrew Burgess's message of "Mon, 29 Apr 2024 13:59:38 +0100") References: <20240416-dwarf-race-relocate-2-v1-0-1fc912e95e87@tromey.com> <20240416-dwarf-race-relocate-2-v1-1-1fc912e95e87@tromey.com> <87cyq8pbnp.fsf@redhat.com> X-Attribution: Tom Date: Mon, 29 Apr 2024 14:04:50 -0600 Message-ID: <87y18wdjfh.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) 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: 97.122.86.252 X-Source-L: No X-Exim-ID: 1s1XF5-00166O-1Y X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-122-86-252.hlrn.qwest.net (murgatroyd) [97.122.86.252]:38562 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Org: HG=bhshared;ORG=bluehost; X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfB1dfUR6a6dgEDAWmz/4kQgs9c7WVMAOLJpBNma8z4V8SSmcsh2Tc6me2TrVg0sNGOaAhsDyBMxgNCYqL2OJ4mlyxPNSC+y3eSKPSIIFw3fB4Vnt+Ust MUwBQoIq8bhjL+7+ZAHHgRhhscSp9XOvtyoVkdHQIj2sNCO1dwr204rW6bFV+a6vjrRkd907TaP+Vu3PRPivCttnwYmylNpxeg0= X-Spam-Status: No, score=-3015.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: Andrew> So, I don't know the details of the DWARF reader too well, so my Andrew> attempt to review this patch might be just wasting your time. Not at all. Thank you for looking at it. >> dwarf2_per_objfile::adjust applies gdbarch_adjust_dwarf2_addr to an >> address, leaving the result unrelocated. However, this adjustment is >> only needed for text-section symbols -- it isn't needed for any sort Andrew> I didn't know if the use of the word 'symbols' here was significant. Andrew> gdbarch_adjust_dwarf2_addr operates on addresses, and I guess symbol Andrew> could be a synonym for address in some contexts. But the addresses here Andrew> do seem to be .text addresses, so clearly there's some important Andrew> distinction that I'm not understanding. The basic idea of this series is to note that gdbarch_adjust_dwarf2_addr is only really needed when computing the address of a full symbol. In other cases, it is just extra work. Part of this observation is from looking at the sole implementation of this hook. This is an abstraction violation, of course, and so maybe the hook ought to be renamed. Certainly other arches should not use it -- in fact, even MIPS shouldn't use it, it's a giant hack, and probably incorrectly implemented to boot (for example, is it intentional that minsym lookups here examine all objfiles? Because they do). Anyway, the MIPS hook implementation looks to see if a given DWARF symbol is really a MIPS16 (or MicroMIPS) symbol. However, this information isn't relevant to the first round of DWARF scanning. For one thing, in the scanner, symbols don't have addresses. So, fixing up the address doesn't matter. Now, text addresses are needed a little -- to map an address to a CU. However, the "un-fixed" address is perfectly suitable for this as well (and these mappings are done by ranges anyway). Andrew> A follow on question. Looking through gdb/dwarf/ there seem to Andrew> be several other places where the addrmap_mutable::set_empty is Andrew> called, and in at least some of those places the addresses are Andrew> still being adjusted. E.g.: Andrew> dwarf2_ranges_read Andrew> cooked_indexer::check_bounds Andrew> cooked_indexer::scan_attributes Andrew> Why do these not need changing? These are all changed in patch #2. Andrew> And an additional question. Are lookups in these maps not done Andrew> via the two ::find_per_cu functions? Which are passed, and are Andrew> documented to expected an un-adjusted (i.e. have Andrew> text_section_offset removed) address. Andrew> If we don't add text_section_offset in to begin with doesn't Andrew> that cause problems? Or maybe the bit I'm missing is that the Andrew> two paths you've changed already are adjusted? Yes, the lookups might be done via find_per_cu. And yes, this takes an unrelocated address. The current code labors under the misapprehension that this gdbarch transform is meaningful to the index. IIRC the previous psymtab code had this same incorrect idea, and so I preserved it in the cooked indexer without looking too deeply into it. Whether the addresses are relocated or not is a bit of a red herring. The 'adjust' method took this into account, by applying the runtime offset, calling the gdbarch method, and then un-applying the offset. However, I believe there's just no need to call this arch hook at all in the indexes -- only for full symbols, where it affects the MIPS ABI. I hope this helps. And if not, please let me know and I can try some more. I feel like I'm not explaining it very well. thanks, Tom