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 _______________________________________________ Toolchain-devel mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/toolchain-devel
