From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta34.uswest2.a.cloudfilter.net (omta34.uswest2.a.cloudfilter.net [35.89.44.33]) by sourceware.org (Postfix) with ESMTPS id EEE273858C41 for ; Sun, 5 Nov 2023 16:48:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EEE273858C41 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 EEE273858C41 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=35.89.44.33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699202917; cv=none; b=f9YOAZaRC8ueOiKc0FMUUHYXvMhcBk2FMusRPw7AsGmFl+f7pr4Lx4CvNIWFtyaLqrYgQSsn79VyY8D5CS+X4q5J6T9qmxyBkX0OqhKJJpHvR5GEOqj7Y3qA1sX1gqn3cm6vv+53PW3uYL6c7uqjz+ywl1EP5BgGXJxCXf7ET4c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699202917; c=relaxed/simple; bh=a0eI1EKDXQBpZzMI9r+hMofLRo73NyMIExVEheNTbkA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=EuGOFkB5/x2B1mIdzmdSejE4582qbJEN+vB7GTbLmOVAUhS5OODuRjVQSaT1BkMRn7YQ6tMdVTzeCOf55DkjzkNOAjU/9jttvIkvoUDLeypgZT01/y970D2Y/cMsLeFgm9FBlk7N2PQvtfBW2Q0R5sSlyDG+IE7E6088JqmN2po= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from eig-obgw-6008a.ext.cloudfilter.net ([10.0.30.227]) by cmsmtp with ESMTPS id zc3rqGxn48HtezgIcq8JZ7; Sun, 05 Nov 2023 16:48:34 +0000 Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTPS id zgIcqcIgw79UBzgIcq0upV; Sun, 05 Nov 2023 16:48:34 +0000 X-Authority-Analysis: v=2.4 cv=YqEc+qUX c=1 sm=1 tr=0 ts=6547c762 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=OWjo9vPv0XrRhIrVQ50Ab3nP57M=:19 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=BNY50KLci1gA:10 a=Qbun_eYptAEA:10 a=dzWzf_mpAAAA:8 a=XjiAHYQXBf_xuVxpMI4A:9 a=b4DR9a7p2ZdsqdHBznES: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=cu4Jpblud3vrrm0nAbRb7Qq6KoBpFO2y5Kh94/y1JzA=; b=efzDy0NfvQzOBIvYpxcTAfnvx/ 7wYr5rWVi9Wtm9HjwKi3Ylxi2LcltlL0P2Ihw2ocKipOLLsu+S1VVNtn1quVvW+Rgieor1Rfqccxa vowG0u7bOh/m0UZAy2djWlenU; Received: from 97-122-77-73.hlrn.qwest.net ([97.122.77.73]:57542 helo=prentzel) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1qzgIb-002YSo-2U; Sun, 05 Nov 2023 09:48:33 -0700 From: Tom Tromey To: Simon Marchi Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH 00/30] Baby step for objfile splitting References: <20231029-split-objfile-2023-bound-sym-october-v1-0-612531df2734@tromey.com> X-Attribution: Tom Date: Sun, 05 Nov 2023 09:48:53 -0700 In-Reply-To: (Simon Marchi's message of "Thu, 2 Nov 2023 23:59:05 -0400") Message-ID: <871qd4tabu.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: 97.122.77.73 X-Source-L: No X-Exim-ID: 1qzgIb-002YSo-2U X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-122-77-73.hlrn.qwest.net (prentzel) [97.122.77.73]:57542 X-Source-Auth: tom+tromey.com X-Email-Count: 6 X-Org: HG=bhshared;ORG=bluehost; X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfESFjwWHIDQEoE3D7OPm4hxv7bZ6n06hmLLfeKJsh2O12lBq9VY4bXlS5ryrI1iHDCbzKc80iQfpn2oN9q5OZN4GIsuCZ8pL2FWw7JYEkYvTn9e8TcnC ko9mOgZNxgA5Z2r/3ZkYR2EqdnAM61uEyFvG9ixz3+8Gwx+Q+2QDfQRbICkiTfqydgaqlYMJQfdYzMetwy9P3Uuvqigr1IJoIBM= X-Spam-Status: No, score=-3018.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: >>>>> "Simon" == Simon Marchi writes: >> The longer term idea here is to then add an objfile member to >> block_symbol. After this, it would be relatively simple to change >> symbols to be relocated at point of use. (This would be a significant >> step toward objfile splitting, but there's even more to do after >> that...) Simon> I started to read this series, and I don't quite grasp why it's useful Simon> to expand the use of the block_symbol structure specifically. If a Simon> function returns or accepts a struct symbol today, once the struct Simon> symbol is made objfile-independent, that function will then need to Simon> return or accept a bound_symbol structure (which does not exist yet) Simon> containing a a symbol and an objfile (just like bound_minimal_symbol). Simon> But I don't see why the block comes into play. Presumably, a function Simon> that doesn't care about the block today won't care about the block Simon> after. Am I missing something? I'm not so familiar with the Simon> symbol-related code. I went through the series again. I found a couple of spots where a bound_symbol would be good to have, so v2 will include that change. Overall, though, I think block_symbol is probably ok in this series. It's maybe not the absolute ideal, but on the other hand it's relatively harmless to use, and in a lot of places it is convenient. The main thing that makes it ok, IMO, is that symbol lookup has to return a block_symbol because the parsers want to track the smallest enclosing block. This choice then spreads through the code a bit. Also, read_var_value sort of "wants" to take a block_symbol. Historically you could pass NULL as the block, but this lead to confusion in some places, plus some arguable bug -- e.g., how symbol value computation is handled in Python. Making this change, again IMO, improves the code by removing something to think about. When I say this isn't the ideal, I guess if I was writing all this from scratch, I'd probably just give a symbol a backlink to its block, and then have blocks link to the symtab somehow. But then there are a dozen things I'd do differently, because the way symbols are done in gdb is bad. Unlike the case with minsyms (or psyms or line tables), splitting symbols in gdb can't really be done all at once. IMO. There are just too many things to touch. There's a reasonably complete list on the wiki. If you do read through the series and find a spot you think would be better off using bound_symbol, let me know and I'll make the change. In my search I found the tracepoint.c patch and the symmisc.c patch. But maybe there are others, it's sometimes hard to tell. Tom