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

[Andrew Cagney <ac131313@redhat.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?)?

The method register_addr() is a static interface between the nat code 
and the ptrace code, not the core of GDB and the ISA/ABI.  Hence, it 
doesn't belong in the architecture vector (which is for interfaces 
between the latter two).

As for implementation, there are two choices:

- as kevin did
- as a function that contains a switch to handle the specific cases

That leaves the question, should the function live in mips-linux-nat.c?

Andrew