From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alt-proxy28.mail.unifiedlayer.com (alt-proxy28.mail.unifiedlayer.com [74.220.216.123]) by sourceware.org (Postfix) with ESMTPS id 2C5323858C50 for ; Fri, 2 Dec 2022 20:59:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2C5323858C50 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 cmgw10.mail.unifiedlayer.com (unknown [10.0.90.125]) by progateway1.mail.pro1.eigbox.com (Postfix) with ESMTP id 267311003F61B for ; Fri, 2 Dec 2022 20:59:22 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id 1D7xpWI83ueSu1D7xpDH8c; Fri, 02 Dec 2022 20:59:22 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=dqwet3s4 c=1 sm=1 tr=0 ts=638a672a 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=y3a06xyXucUCQh7JSmEA: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=4COEDU8wglcB8VFE8U96TC+jcPCREub5nJGAUR/xLhk=; b=nLUaib+37iV/QzmF9clGwXdLz4 qrM9//amPvf4pkMimPrBdab4zVtCBMG6cFXDUa9xZUOJ+GnQlN7u3NLfQXWVb0nrfwMGZ55se73u+ ZiZqkWbGukPtW62V6zADd3oyZ; Received: from jordan3.gnat.com ([205.232.38.251]:56352 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1p1D7x-004CvM-EX; Fri, 02 Dec 2022 13:59:21 -0700 From: Tom Tromey To: Simon Marchi via Gdb-patches Cc: Tom Tromey , Simon Marchi Subject: Re: [PATCH 1/3] gdb: add inferior_target_stack_changed observer, use it to clear auxv cache References: <20221129025048.44490-1-simon.marchi@polymtl.ca> <874jugo3av.fsf@tromey.com> <7f956f4e-1418-2e15-c2f1-418d0f2e84d4@polymtl.ca> X-Attribution: Tom Date: Fri, 02 Dec 2022 13:59:16 -0700 In-Reply-To: <7f956f4e-1418-2e15-c2f1-418d0f2e84d4@polymtl.ca> (Simon Marchi via Gdb-patches's message of "Fri, 2 Dec 2022 14:36:51 -0500") Message-ID: <87cz91ldy3.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.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: 205.232.38.251 X-Source-L: No X-Exim-ID: 1p1D7x-004CvM-EX X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: jordan3.gnat.com (murgatroyd) [205.232.38.251]:56352 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3021.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: >> It seems like overall it would be better to have the auxv cache just be >> some member of 'inferior'. Then these indirections and observers >> wouldn't be needed -- the inferior could just manage it directly. Simon> I kind of like observers, it gives the impression that things are Simon> decoupled... but yeah in practice it just adds unnecessary layers of Simon> indirection. I like them depending on the situation. For me it's sort of like attaching a registry entry. If there are "optional" modules that need to attach data to a core data structure (e.g., something arch-specific attaching to an objfile) then a registry entry makes sense. But for things that are inherit attributes of an object, a registry entry would be sort of absurd. I see observers the same way. If two modules "should be" decoupled, like if one is a core bit of gdb and another is some thing that might be not compiled in, or only useful in some situations, then an observer is a good way to convey state changes. For auxv, IIUC, it's intended to always cache this data, which is somewhat intrinsic to the inferior and the module must track some aspects of the inferior's lifetime. To me this says, just make some auxv cache object as a field of inferior and let the inferior tell it directly. That said I wouldn't expect a change here since it's already written. Just wouldn't object; and I guess it's worthwhile to try to articulate the principle for new code. thanks, Tom