This is the mail archive of the gdb-prs@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]

pending/1001: Re: [RFA] Add support for 64-bit MIPS GNU/Linux targets


>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 (&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
 
 
 
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:


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