From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by sourceware.org (Postfix) with ESMTPS id 317A6389851F for ; Thu, 30 Apr 2020 15:48:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 317A6389851F Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 9A58328F822; Thu, 30 Apr 2020 11:48:38 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 2dVUpleSZKky; Thu, 30 Apr 2020 11:48:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 5082728F99A; Thu, 30 Apr 2020 11:48:38 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 5082728F99A X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 59jSP8cPdgmH; Thu, 30 Apr 2020 11:48:38 -0400 (EDT) Received: from [10.0.0.193] (unknown [192.222.164.54]) by mail.efficios.com (Postfix) with ESMTPSA id 2B59428F999; Thu, 30 Apr 2020 11:48:38 -0400 (EDT) Subject: Re: [PATCH 0/7] Make gdbarch.sh shellcheck-clean To: Tom Tromey , Simon Marchi Cc: Simon Marchi via Gdb-patches References: <20200428214655.3255454-1-simon.marchi@efficios.com> <878sie57an.fsf@tromey.com> <671ce996-8de0-a21d-b11d-91052c3d4f9b@simark.ca> <87o8r92gpw.fsf@tromey.com> From: Simon Marchi Message-ID: <294859b8-cefe-c6be-6e07-6157d65c9124@efficios.com> Date: Thu, 30 Apr 2020 11:48:37 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <87o8r92gpw.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 15:48:42 -0000 On 2020-04-30 10:25 a.m., Tom Tromey wrote: >>>>>> "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 > Ok, so the gdbarch object would stay somewhat similar to what it is now, it would contain function pointers that can be set at runtime. Somehow, I was trying to think of how to do it by defining gdbarch as a base class with gdbarch methods as virtual methods of this class. But that does not work well with how gdbarch objects are constructed today. We would have to define one concrete subclass for each possible resulting gdbarch. I don't think that's possible, as there are just too many combinations. Your plan is more realistic. Simon