Invalid registers
Andrew STUBBS
andrew.stubbs@st.com
Tue Jul 12 16:16:00 GMT 2005
On Mon, 11 Jul 2005 19:47:01 +0100, Marcel Moolenaar <marcel@cup.hp.com>
wrote:
> Given that registers are available when a value has been supplied,
> it's logical to assume (a priori) that a register is unavailable
> when no value has been supplied. A register's valid "bit" allows
> for this since there are 2 states that indicate unavailability:
> One that indicates a temporary state (0) and one that indicates a
> permanent state (-1). The initial state of a register is the temporarily
> unavailable state, which triggers fetching the register from the
> target. The target can change the state to permanently unavailable
> or supply the value (it can also, theoretically at least, leave the
> state unmodified and not provide a value). Hence, the a priori
> assumption that registers are unavailable when no value has been
> supplied (i.e. when the valid "bit" is not 1) seems to yield good
> behaviour when implemented as such. I would say then that gdb knows
> when a value is not available.
Thanks, I did look at this before I posted, but I concluded that I was not
what I was looking for. I mean, how would the target know what frame you
were in?
I do not know what it means for a register to be invalid in the target.
Might it be because some registers are not available when, for example,
the FPU is disabled?
In any case, my target is always happy to supply registers.
Andrew Stubbs
More information about the Gdb
mailing list