Re: Invalid registers

[Marcel Moolenaar <marcel@cup.hp.com>]

On Jul 11, 2005, at 8:49 AM, Daniel Jacobowitz wrote:

> On Mon, Jul 11, 2005 at 04:39:51PM +0100, Andrew STUBBS wrote:
>> Hi,
>>
>> I have been having a little trouble updating from GDB 5.3 to GDB 6.3.
>>
>> It used to be the case that GDB would report '*value not available*' 
>> (for
>> SH - I haven't checked other architectures) if the value of a 
>> register is
>> not known in the current stack frame. However, it no longer does this.
>> Since I assume it has not acquired some way to find out what that 
>> value
>> was, I also assume this is somehow broken.
>
> How's it supposed to know that the value is not available?

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.

Unfortunately, there are various bugs in this respect. A typical
bug is to test for (register_valid_p[regnum]) to check if the
register is cached, which ignores the <0 state for unavailable.

-- 
  Marcel Moolenaar         USPA: A-39004          marcel@xcllnt.net