Re: RFA: assert that target_fetch_registers did its job

Andrew Cagney
2004-08-07T16:13:21Z

> 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