This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

"Ulrich Weigand" <> 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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]