Re: [rfc/rft] [3/4] Untangle register_addr - v2 - mips-linux

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Apr 25, 2007 at 02:16:44AM +0200, Ulrich Weigand wrote:
> I had assumed people would be building GDB for a different target in
> such cases -- if the mips-linux target is used, I agree my proposed
> patch is broken.

I can't say for sure whether they should be, but I know I and others
use a foo-linux gdb to talk to kgdb, or to talk to associated JTAG
stubs.  Of course, we might be able to make GDB consider that a
different OSABI.  But it's not easy to tell a static linked program
from a kernel image.

> 
> So I guess we're back to distinguishing between a gdbarch method of
> providing registers that cannot be fetched and stored, and in addition
> a target_ops method -- which in the case of a target using the 
> trad_ptrace helpers should be made available somehow ...
> 
> In any case, I still like to get the bulk of the register_addr patch
> set committed soon -- the whole cannot_fetch_register discussion is
> really an independent topic.  The following patch contains just the
> part to move register_addr to mips-linux-nat.c and leaves the
> CANNOT_FETCH_REGISTER situation completely unchanged.  Would that
> be OK with you for now?

Yes, this patch looks fine to me (with the Makefile.in dependency
update, of course).

-- 
Daniel Jacobowitz
CodeSourcery