Re: New xxx_register gdb-arch function vs pseudo register

[Andrew Cagney <ac131313 at cygnus dot com>]

Stephane Carrez wrote:

> 2/ Try to use the pseudo registers framework.
>    The problem here is that the soft registers are not aliases to other
>    registers (nor combination of them).  There are several places in GDB-core
>    where we only take into account the NUM_REGS and not NUM_REGS+PSEUDO_REGS.

> [...]

>    Pros: No new multi-arch function, may be fix some PSEUDO_REGS support (not sure)
>    Cons: More complex, may change the semantics of PSEUDO_REGS

Could I encourage you to persue this alternative.    It isn't that I
have something against extra multi-arch entries (ok I do but not in this
case :-) but rather that the problem you're describing (registers living
in memory space) is far more common than you might think.  Off hand, I
can think of at least three targets that have an identical problem.  In
those cases people ended up shoving hacks into either/and SIM and the
target stub :-(.

> 
>    For example, the frame structure must handle the saved registers but
>    it ignores the PSEUDO_REGS.  If I want to use the pseudo registers framework,
>    it will not work because the soft registers can be saved on the stack.
> 
>    There are a few places like this which must be fixed.

And it won't be easy - the more you look the more tricky it gets, the
expression evaluator is involved.  If you want I can try some bad ascii
art drawing out how I think it should work.

	Andrew