This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: ARM and virtual/raw registers
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: Richard dot Earnshaw at arm dot com, gdb at sources dot redhat dot com
- Date: Sat, 11 May 2002 19:41:00 +0100
- Subject: Re: ARM and virtual/raw registers
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> > If, as I understand your previous postings to imply, having pseudo
> > registers stored in the cache is wrong, why does regcache_read() allow
> > them?
> >
> > regcache_read (int rawnum, char *buf)
> > {
> > gdb_assert (rawnum >= 0 && rawnum < (NUM_REGS + NUM_PSEUDO_REGS));
>
> Lets just pretend you didn't see that :-)
> Some existing mechanisms store pseudo-register values in the cache. In
> addition ``NUM_REGS'' is overloaded - it controls too many aspects of
> GDB - num regs in G packet, num regs to save across an inferior function
> call, ...
>
> Andrew
>
>
Argh! I've just come across another nasty gotcha in this code, if I try
to make it so that the regcache does not hold any pseudos: There's an
implicit assumption that all the physical registers will preceed the
pseudo registers.
This is a major problem when I want to implement the banked registers for
the ARM, since then r8 through r14 (which must have regnums 8 through 14
for stabs debug info to work correctly), need to be pseudo registers (they
must access the correct physical register for the current processor mode);
which means they must appear in the middle of the register range.
I can make my arm_register_read function correctly remap the register
numbers, but then I run into the problem that REGISTER_RAW_SIZE is used
both above and below the regcache.
Would you be averse to me creating a gdbarch entry for
REGISTER_REGCACHE_RAW_SIZE (which defaults to REGISTER_RAW_SIZE) and then
using that when directly accessing the cache?
R.