This is the mail archive of the gdb-patches@sources.redhat.com 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: [RFA] Add support for 64-bit MIPS GNU/Linux targets


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



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