Re: [PATCH v3] gdb: bfin: new port

[Pedro Alves <pedro@codesourcery.com>]

On Wednesday 15 December 2010 13:02:02, Mike Frysinger wrote:
> On Tuesday, December 14, 2010 17:00:13 Mike Frysinger wrote:
> > On Tuesday, December 14, 2010 16:31:22 Pedro Alves wrote:
> > > Can you explain why are the PC and CC registers pseudo
> > > registers, but supported as being raw registers anyway?  Couldn't
> > > gdb compute them itself from the other registers, with
> > > gdb's pseudo register support (gdbarch_pseudo_register_read|write)?
> > > googling I found you mentioning that the "CC pseudo register can
> > > be deduced from the ASTAT register", though further googling doesn't
> > > find any mention of what ASTAT is.  I'm sure there's a good reason,
> > > I'm probably just missing a comment somewhere.
> > 
> > CC is actually a single bit in the ASTAT (arithmetic status) register, but
> > often is treated as an actual register in much of the ISA.  such as
> > assignments or logical tests.  you can do "<reg> = CC" and "CC = <reg>",
> > but you cant do this with any other ASTAT bit (like AZ, AN, etc...).
> 
> another data point: gcc itself treats CC as a register.
> 
> btw, the name is short for "Control Code"

Thanks for the explanations.  This makes it so that the ASTAT.CC bit
can easily end up out of sync with the CC register in gdb's
regcache then, right?  E.g., "p $cc = 1; p $asat" will still show the
$asat.cc as 0, IIUC.  Does the kernel actually store CC on its
own slot in the register stack?  I ask because I see it commented out
in bfin_regmap in gdbserver.  If $cc was a pseudo-register _managed_ by
gdb (computed from ASAT), then this out-of-sync-ness would never happen.

Similar comments apply to the PC.  I see:

> +static int bfin_linux_sigcontext_reg_offset[BFIN_NUM_REGS]
...
> +  21 * 4,      /* %reti */
> +  22 * 4,      /* %retx */
> +  -1,          /* %retn */
> +  -1,          /* %rete */
> +  21 * 4,      /* %pc */

So, it's really the same stack slot as reti.

and in gdbserver:

> +static int bfin_regmap[] =
> +  -1 /* PT_USP */, PT_SEQSTAT, PT_SYSCFG, PT_PC, PT_RETX, PT_RETN, PT_RETE,
> +  PT_PC, -1 /* PT_CC */,

(PT_PC used to get at reti).

It all looks like you should really make the PC and the CC registers
pseudo registers handled by gdb, and not pass them on the remote
protocol wire, getting rid of all the possibility of confusing
out-of-sync iret/pc, astat/cc.

-- 
Pedro Alves