This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
pending/1001: Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: gdb-gnats at sources dot redhat 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: pending/1001: Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets
- References: <1021223225021.ZM25698@localhost.localdomain> <20021223235639.GA6927@nevyn.them.org> <3E1A1E43.10201@redhat.com> <20030107231621.GF20617@nevyn.them.org>
>Number: 1001
>Category: pending
>Synopsis: Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Fri Jan 31 05:48:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:
>Release:
>Organization:
>Environment:
>Description:
> 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?)?
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
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: