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: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: Kevin Buettner <kevinb at redhat dot com>, gdb-patches at sources dot redhat dot com
- Date: Tue, 7 Jan 2003 18:16:21 -0500
- Subject: Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets
- References: <1021223225021.ZM25698@localhost.localdomain> <20021223235639.GA6927@nevyn.them.org> <3E1A1E43.firstname.lastname@example.org>
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 (®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?)?
MontaVista Software Debian GNU/Linux Developer