[RFA] Add support for 64-bit MIPS GNU/Linux targets
Daniel Jacobowitz
drow@mvista.com
Tue Jan 7 23:16:00 GMT 2003
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?)?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
More information about the Gdb-patches
mailing list