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

[Mike Frysinger <vapier@gentoo.org>]

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

On Wednesday, December 15, 2010 13:00:27 Pedro Alves wrote:
> On Wednesday 15 December 2010 17:07:11, Mike Frysinger wrote:
> > > 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).
> 
> I see.  Does the correct pc register depend on context (in exception, in
> interrupt, in normal code, in whatnot), or is it always fixed per stub?  If
> the latter, it sounds like something that should be handled by a xml target
> description that somehow tells gdb which register is the pc (sounds more
> complicated than it is, I think).  If the former, is there any way to tell
> which is the correct register by reading some other register, perhaps?
> Otherwise, yeah, best keep it a separate register, which is a bit of a
> shame...

in practice, i think the reg would be fixed per stub, but there isnt a 
requirement for it to be.

in the Linux case, the userspace PC often shuffles between all the registers, 
and eventually shoves it into RETI (due to how the kernel resumes user mode 
from supervisor mode).  userspace doesnt actually know about this ... it 
merely asks via ptrace for the PT_PC register.  changing things in the kernel 
could break this assumption (RETI == PC), but the ABI would be preserved since 
we have the PT_PC indirection.

conceivably, a stub operating in a higher mode could pick it from the right 
register immediately rather than doing the delayed loading seen in the linux 
kernel.

the Blackfin simulator actually does have a dedicated PC register, so in that 
case the request is fulfilled from that source.

having the stub export the indirect logic on the fly might be possible, but 
i'm not sure the extra complication required is an improvement.
-mike

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