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: Sun, 12 May 2002 16:25:19 +0100
- Subject: Re: ARM and virtual/raw registers
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> > However, in this situation,
> > pseudo_rengo("r0") != regcache_regno("r0"), yet we effectively have
> >
> > REGSITER_RAW_SIZE (pseudo_regno ("r0"))
> > and
> > REGISTER_RAW_SIZE (regcache_regno ("r0"))
>
> Sorry, I still don't understand.
In my view of things, the domain of the result returned by pseudo_regno()
is
0..Num_pseudos,
and the domain of regcache_regno() is
0..NUM_REGS
But we have cases where the two functions return a different number for
the same register; more precisely, we might encounter the situation where
pseudo_regno ("int_reg0") == regcache_regno ("float_reg5")
and clearly in this case one of these will give the wrong answer if used
to call REGISTER_RAW_SIZE().
> Sorry, I still don't understand. Given pseudo-registers, the name of
> the function ``register_raw_size'' is definitly overloaded. However,
> per the patch very recently committed, the norm should now be:
> register_raw_size() == register_virtual_size() == TYPE_LENGTH
> (register_virtual_type()) (which makes them all badly named :-)
This has nothing to do with the raw and virtual sizes being different, or
the raw and virtual types being different.
> Even more ruthless. Try a register layout of:
> --
> raw normal r0..r15
> raw someothers
> raw floats
> raw bank r0..r15
> raw still more
> --
> pseudo r0..r15
> mapped onto either normal or banked
> pseudo floats
> mapped onto floats
> and so on, for instance, explict register names to identify normal and
> banked r0.
> --
> which completly separates the raw and pseudo registers. The function
> register_name() becomes:
>
> if regnum < NUM_REGO
> return "";
> else
> return yourtable[regnum - NUM_REGS];
Hmm, not quite, I'm trying to bury the regcache even deeper than that...
It simply does not exist to most of core-gdb, except by calling through
arm_register_read(), which is the only function that knows how to map a
regno onto its regcache entry.
R.
R.