+ register_addr_data =
+ register_gdbarch_data (init_register_addr_data, 0);
+
gdbarch_register_osabi (bfd_arch_mips, 0, GDB_OSABI_LINUX,
mips_linux_init_abi);
add_core_fns (®set_core_fns);
Blech. So, the way _I_ would have done this would have been to put
this in the tdep structure. In fact I have several patches which add
similar methods to the tdep structure, for signal handling. Of course,
this is not compatible with the way Andrew asked to leave the tdep
struct in mips-tdep.c. This is OK for now, but hopefully we can get
rid of it eventually. We could multi-arch register_addr (is that
appropriate? It's a native-only function, isn't it?) to do that.
Using the gdbarch data mechanism is a good idea - it keeps that
architecture dependency local to that file. It definitly doesn't belong
in the tdep structure since nothing, other than this file, needs it.