Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Simon Marchi <simark@simark.ca>
Cc: Tom Tromey <tom@tromey.com>,
	 Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>,
	 Simon Marchi <simon.marchi@efficios.com>
Subject: Re: [PATCH 0/7] Make gdbarch.sh shellcheck-clean
Date: Thu, 30 Apr 2020 08:25:31 -0600	[thread overview]
Message-ID: <87o8r92gpw.fsf@tromey.com> (raw)
In-Reply-To: <671ce996-8de0-a21d-b11d-91052c3d4f9b@simark.ca> (Simon Marchi's message of "Wed, 29 Apr 2020 20:34:21 -0400")

>>>>> "Simon" == Simon Marchi <simark@simark.ca> 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<typename T>
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<bfd_endian> 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<T>::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


  reply	other threads:[~2020-04-30 14:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28 21:46 Simon Marchi
2020-04-28 21:46 ` [PATCH 1/7] gdb: fix shellcheck warnings SC2059 (variables in printf format string) in gdbarch.sh Simon Marchi
2020-04-28 21:46 ` [PATCH 2/7] gdb: fix shellcheck warnings SC2086 (missing double quotes) " Simon Marchi
2020-04-28 21:46 ` [PATCH 3/7] gdb: fix shellcheck warnings SC2006 (use $() instead of ``) " Simon Marchi
2020-04-28 21:46 ` [PATCH 4/7] gdb: fix shellcheck warnings SC2166 (&& and !! instead of -a and -o) " Simon Marchi
2020-04-28 21:46 ` [PATCH 5/7] gdb: fix shellcheck warnings SC2034 (unused variable) " Simon Marchi
2020-04-28 21:46 ` [PATCH 6/7] gdb: fix shellcheck warnings SC2154 (referenced but not assigned) " Simon Marchi
2020-04-28 21:46 ` [PATCH 7/7] gdb: silence shellcheck warning SC2162 (use read -r) " Simon Marchi
2020-04-29 21:08 ` [PATCH 0/7] Make gdbarch.sh shellcheck-clean Tom Tromey
2020-04-30  0:34   ` Simon Marchi
2020-04-30 14:25     ` Tom Tromey [this message]
2020-04-30 15:48       ` Simon Marchi
2020-05-07  1:59         ` Tom Tromey
2020-05-10 18:57   ` Pedro Alves
2020-05-10 21:36     ` Simon Marchi
2020-05-11 16:55     ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o8r92gpw.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    --cc=simon.marchi@efficios.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox