This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]