This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: pseudo registers in the regcache
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Richard dot Earnshaw at arm dot com
- Cc: gdb at sources dot redhat dot com, Elena Zannoni <ezannoni at redhat dot com>
- Date: Sat, 18 May 2002 14:08:05 -0400
- Subject: Re: pseudo registers in the regcache
- References: <200205181048.LAA25913@cam-mail2.cambridge.arm.com>
> I think the line-in-sand approach to just banning values in
>> pseudo-registers post register-read is both better and easier
>
>
> Don't get me wrong, I'm all in favour of tightening up the definitions.
> What frightens me is the length of time that the "legacy" interfaces will
> have to remain (and the rate at which we are growing the number of them).
Knowing some of the older targets, I don't expect most to be affected at
all by such a change - they already have a simple 1:1 cache layout and
only raw registers. Of the others, the ones that are most affected by
such a change are also the ones that most desperatly need a cleanup -> MIPS.
Are there too many legacy interfaces? I just did a:
$ grep legacy *.h | grep -v -e '^gdbarch' -e '^arch-'
so I think we need more of them :-^ :-^
I believe most of the current legacy code is to prop up non-multi-arch
architectures and get around limitations in the multi-arch framework.
As the old targets go and the problems are fixed the number will start
to go down.
Here, yes, we've got different situtatioin. Check the thread:
http://sources.redhat.com/ml/gdb/2001-03/msg00124.html
for various opinions on how to approach this.
(Hmm, I've been falling down on the legacy side but I have managed to
doco the multi-arch process.)
>> Shouldn't be too hard to do this using the tweaked regcache - that uses
>> regcache->descr->nr_registers instead of NUM_REGS + NUM_PSEUDO_REGS. In
>> fact [evil laughter :-)] I can think of a few other things that it could
>> disallow:
>> - holes in the register cache
>
>
> Hmm, I think this will depend on who "owns" the regcache layout. If it's
> a property of the "target" vector, then that is reasonable. If it's a
> property of the tdep code (gdbarch vector), as I think it should be, then
> I don't think it is reasonable.
Sorry ``hole'' is a loose term. I'm thinking of the nasty things that
can be done with register_byte() and register_raw_size(). Regsters of
size zero, gaps between RawRn and RawRn+1, register_byte(PseudoRn) ==
register_byte (RawRm) + CONST, .... The MIPS is guilty as charged.
----
Another problem with the way things currently work. OP_REGISTER is
implemented as an offset and size into the register cache.
read_register_bytes is then used to read it.
I should add an interface to regcache to keep that working :-(
Andrew