This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Example code: gdb pseudo-registers
- To: Stan Shebs <shebs at apple dot com>
- Subject: Re: Example code: gdb pseudo-registers
- From: Michael Snyder <msnyder at cygnus dot com>
- Date: Thu, 13 Jul 2000 09:18:31 -0700
- CC: gdb-patches at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <396D07F2.6892@cygnus.com> <396D2752.7EC33ECE@apple.com>
- Reply-To: msnyder at cygnus dot com
Stan Shebs wrote:
>
> Michael Snyder wrote:
> >
> > Here is an example of how you would use the pseudo-register feature.
>
> Good stuff! It occurs to me that although this is primarily an
> implementor's feature, we should probably say *something* in the
> manual? At the very least, user modification of a user-visible
> register will cause other user-visible registers to magically
> change, and we should document that this could happen, and that
> the exact effects are arch-specific.
Good point. I might point out that one of the major motivators
for this work was the user-unfriendly way in which GDB treats
the "$fp" register. When you say "print $fp", you always get
the contents of an actual hardware register (unles the chip
doesn't have an FP). But when you say "info reg fp", you
sometimes get a computed value indicating the virtual frame
pointer in a frameless function. I'm not sure if THAT little
goodie was ever documented... ;-) Anyway, we wanted to
be able to move that second case into a pseudo-register called
"virtual-FP" (or something).
Aside: the m32r has two stack pointers, 'user' (spu) and
'interrupt' (spi). GDB also displays a third register (sp)
which I forget whether it's virtual or actually reflects
something on the hardware. 'sp' always mirrors either spu
or spi, depending on the 'interrupt' bit in the status reg.
Changing one changes the other. I dunno if we ever documented
that... ya know, the user will figure it out eventually... ;-)