This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: The REG_NUM and REGISTER_BYTES problem
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 03 Dec 2001 00:22:28 -0500
- Subject: Re: The REG_NUM and REGISTER_BYTES problem
- References: <3C084D16.4090205@cygnus.com> <20011202180304.A7998@nevyn.them.org>
> Well, how will this affect pseudo registers that we can provide but
> that the remote stub can not? I'm pretty sure there are some. Is the
> intent that such registers "should not" be fetched?
Hmm, yes, er, how can I put it? Pseudo registers are a figment of GDB's
vivid imagination? Hmm, perhaphs not.
The theory is that core-GDB delegates _all_ responsibility for the
resolution of such issues to the target architecture. Or to put it
another way, the target architecture is given enough rope to hang its
self :-)
Yes, there are going to be registers that should not be fetched by
remote.c from the target. The trick is that register read/write should
have already intercepted such register requests and mapped them onto
real registers. (ok, I've simplified it a little :-)
Think of it as:
user
-> register read/write (maps cooked to raw)
-> regcache read/write
-> target fetch/store
-> target.c
-> map regnum to target regnum
provided register read/write is implemented correctly, the architecure
is honky dorey.
To give a tangeable example, consider i386's MMX. These 64 bit pseudo
registers can be mapped onto 80 real FP registers. The register
read/write function map's MMX N register onto FP register M.
enjoy,
Andrew