This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Kevin Buettner <kevinb at redhat dot com>,gdb-patches at sources dot redhat dot com
- Date: Tue, 07 Jan 2003 18:59:07 -0500
- Subject: Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets
- References: <1021223225021.ZM25698@localhost.localdomain> <20021223235639.GA6927@nevyn.them.org> <3E1A1E43.email@example.com> <20030107231621.GF20617@nevyn.them.org>
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).
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,
>> 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.
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?)?
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?