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

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: Text/Plain, Size: 3483 bytes --]

On Wednesday, December 15, 2010 11:49:32 Pedro Alves wrote:
> 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.

no, linux does not give CC dedicated space in the signal context.  it does 
look like setting $cc on the command line results in out-of-sync values with 
$astat.  i'll take a look at the pseudo helpers you referenced and see if i 
cant figure out how they work.

> 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.

the trouble with PC is that it isnt always RETI.  with a Linux userspace app, 
the PC is managed indirectly via RETI (by nature of the sequencer).  but this 
all depends on the level the remote stub is operating at.  it could possibly 
be indirectly handled by RETX or RETN or RETE as well.  so i think the PC 
logic needs to be left up to the remote stub to properly manage.  i dont think 
we need to worry about people attempting to screw with any of the supervisor 
level registers (RET[IXNE]) because they arent allowed to in usermode and they 
make no sense unless you're in any of those contexts 
(interrupt/exception/nmi/emulation).
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]