From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gateway24.websitewelcome.com (gateway24.websitewelcome.com [192.185.51.31]) by sourceware.org (Postfix) with ESMTPS id D961C3894E6C for ; Thu, 30 Apr 2020 14:25:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D961C3894E6C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=tom@tromey.com Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway24.websitewelcome.com (Postfix) with ESMTP id 431C43DB4F for ; Thu, 30 Apr 2020 09:25:32 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id UA84j9J9cEfyqUA84jySmc; Thu, 30 Apr 2020 09:25:32 -0500 X-Authority-Reason: nr=8 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=ApsmvmRhNTIuacxOQvxh4zaqhTFso561yxXdBCXWHe8=; b=Bpr9iEmaPx1t3mKw/vHJZ7FA+/ vwi6PN1ULjdoEVRnlYx21IF05ITW00AJgoj3+QqrqPcDEV01DKJvRrcS4Zr5hYQu91P+xnY+zCTos mYrNCq08zDBcCpcsRza/be28z; Received: from 184-96-229-138.hlrn.qwest.net ([184.96.229.138]:39974 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1jUA83-002A2t-UC; Thu, 30 Apr 2020 08:25:32 -0600 From: Tom Tromey To: Simon Marchi Cc: Tom Tromey , Simon Marchi via Gdb-patches , Simon Marchi Subject: Re: [PATCH 0/7] Make gdbarch.sh shellcheck-clean References: <20200428214655.3255454-1-simon.marchi@efficios.com> <878sie57an.fsf@tromey.com> <671ce996-8de0-a21d-b11d-91052c3d4f9b@simark.ca> X-Attribution: Tom Date: Thu, 30 Apr 2020 08:25:31 -0600 In-Reply-To: <671ce996-8de0-a21d-b11d-91052c3d4f9b@simark.ca> (Simon Marchi's message of "Wed, 29 Apr 2020 20:34:21 -0400") Message-ID: <87o8r92gpw.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (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: 184.96.229.138 X-Source-L: No X-Exim-ID: 1jUA83-002A2t-UC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 184-96-229-138.hlrn.qwest.net (murgatroyd) [184.96.229.138]:39974 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NEUTRAL, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 14:25:43 -0000 >>>>> "Simon" == Simon Marchi writes: Simon> Even if you don't plan to do it, if you have ideas of how we could do the Simon> equivalent in pure C++, it would be nice if you could spell them out somewhere. Simon> I think about this some times, but I don't have a clear picture of how the Simon> result could look like. I was thinking that most fields would have a type like: template class gdbarch_wrapper { T m_data; T operator() () const { return m_data; } void set (const T &v) { m_data = v; } }; So, byte order would be gdbarch_wrapper byte_order; Calls like set_gdbarch_byte_order(x,y) would be x->byte_order.set(y); gdbarch_byte_order(x) would be x->byte_order(); Maybe this doesn't provide much value over just plain fields. Types with a predicate would have an additional "is_set" method and maybe wrap an option<> (or similar -- we could probably specialize this for pointers to just check for NULL). Function fields would have an operator() that would forward the arguments. I'm not sure how best to handle method fields, where the gdbarch is passed through. This part makes me suspect that this isn't a good plan. Maybe these could be ordinary methods that forward through the field, with a new type here so that the field's operator() isn't accessible outside struct gdbarch. I suppose gdbarch_wrapper::operator() could handle the gdbarch debugging stuff. I personally would be inclined to remove it -- I have never once used it -- but maybe that's just me. Maybe it could be retained only for function calls. I wrote a bit of elisp last night to do the basic transform (function calls to method calls). That part doesn't seem so hard. Harder is making it a reviewable series, instead of one giant bomb. One plan would be to move struct gdbarch to gdbarch.h (removing the read-only-ness of these files); then convert one field at a time, removing the related old-style functions; then any final cleanups. WDYT? Tom