Re: RFA: assert that target_fetch_registers did its job

[Andrew Cagney <cagney at gnu dot org>]

> Jim Blandy <jimb@redhat.com> writes:
>
>
> > > Perhaps another option would be something like the below: it informs
> > > users that things are not as they seem, and encourages developers to
> > > fix up their targets.  Comments?

I'll disable this while we sort things out.  I've just hit another 
system (PPC/NetBSD) that panics.

While requiring that the inferior always `supply' a register appears 
reasonable (and I agree with the theory) it turns out we don't have the 
mechanisms for indicating all the possible supplied register states (see 
below) and the implementors of the supply code didn't realise that was 
part of the contract :-(

I think we can also just as effectively (and not as fatally :-) use the 
testsuite and something based on ``maint print cooked-registers'' (it 
will need to print state info) to detect mis-behaving inferior code.

> Aren't users going to wind up getting this error message approximately
> one gazillion times when doing debugging on a target which doesn't
> provide all the registers?
>
> I don't know if this is the right approach in general, but if it is I
> think it at least needs a static flag or something to only issue the
> error once per execution.

Here's a brain dump of the current situtation:

A register, be it in the regcache or a frame, can have 4 states (I've 
listed the regcache states where applicable, the frame uses a flag 
`optimised out'):

- invalid (0)
Initial state, yet to probe for the register.

- valid (1)
The inferior was able to supply a full register value.

- unsupported
The register is not available on this system (due to limitations of the 
ptrace interface say).  Yes, there currently isn't a state for this :-(

- unknown (-1)
For what ever reason, the the register isn't known at this point in 
time.  (For CFI because it wasn't saved).

When it comes to using these values, GDB ducks the issue.  If an attempt 
to fetch a frame's register results in a memory problem, an error is 
thrown, if it results in an unknown/unsupported register, zero is 
silently returned.

I think:

- the register cache should just mark up the status of its registers and 
trust that the client will notice the problems

- the frame code should detect unknown / unsupported register accesses 
and throw an error

- the code displaying variables, using register values, should catch / 
incorporate such exceptions in their output vis:

(gdb) print foo
$1 = struct { string = <Memory error at 0x12345>, integer = <Register r3 
unknown>, ...}

however we've a ways to go before this happens.  We've not even killed 
of deprecated_registers[].

Andrew