Re: [PATCH 0/7] Make gdbarch.sh shellcheck-clean

[Simon Marchi <simon.marchi@efficios.com>]

On 2020-04-30 10:25 a.m., Tom Tromey wrote:
>>>>>> "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
> 

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