This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: New xxx_register gdb-arch function vs pseudo register
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: New xxx_register gdb-arch function vs pseudo register
- From: David Taylor <taylor at cygnus dot com>
- Date: Thu, 24 Aug 2000 11:09:09 -0400
- cc: Stephane Carrez <Stephane dot Carrez at worldnet dot fr>, gdb at sourceware dot cygnus dot com
Date: Thu, 24 Aug 2000 20:05:42 +1000
From: Andrew Cagney <ac131313@cygnus.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 the processor I'm working on a port for, some of the registers are
banked, and the pc is actually generated by smashing together two
other registers and then modifying the result... to keep things
simple, I ended up making NUM_REGS 0 -- all registers are PSEUDO_REGS
(some (e.g., fp and sp) more pseudo than others).
Now, I need to capture writes to memory -- all registers are memory
mapped (and there is no memory other than memory mapped registers), so
if you read/write memory, you're actually reading/writing a register...
>
> 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.
Yes, please.
Andrew
David