Re: [0/10] Clean up built-in types

[Jim Blandy <jimb at codesourcery dot com>]

"Ulrich Weigand" <uweigand@de.ibm.com> writes:
> most of the remaining gdbarch-swapped data items are built-in data types.
>
> The following patch set reworks the handling of these types and gets rid
> of the need to swap variables.
>
> The basic idea is to replace all global variables like builtin_type_void
> with a "compatibility macro" referencing the current architecture's
> builtin_type structure:
>
> #define builtin_type_void \
>        (builtin_type (current_gdbarch)->builtin_void)
>
> To make this possible, we need to ensure that:
>
> - the builtin types are never used in a context where the macro version
>   would break (e.g. taking the address of a builtin type)
>
> - all builtin types are in fact represented in the builtin_type
>   per-gdbarch data structure as well
>
> In the future, those compatibility macros can be replaced by directly
> using builtin_type on the appropriate gdbarch at the call site.

At first I was concerned that builtin_type (current_gdbarch) would be
populated too late to be useful, but looking at the code I saw that
referring to builtin_type_ from a gdbarch_init function has always
been broken.

The M32C port creates a bunch of types in its gdbarch_init function,
constructing its own 'void', 'void *', and 'void (*)()' types to avoid
referring to the builtin_type_ variables.  Do you see anything offhand
in m32c-tdep.c:make_types (which is called from m32c_gdbarch_init)
that would be incompatible with this approach?