Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Jan 06, 2003 at 07:24:35PM -0500, Andrew Cagney wrote:
> >+  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 (&regset_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.
> 
> Hmm, should the actual code live in mips-linux-nat.c though?

Well, here's the situation: other files call register_addr.  I think
core-regset?  It's a native only method, but which one we want depends
on the current gdbarch.  I suppose we can just use a gdbarch_data to
handle this, but it seems as if there should be a better way.  Should
it be properly multi-arched (is there any point?)?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer