This is the mail archive of the gdb@sourceware.cygnus.com 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]

Re: m68k stub and DECR_PC_AFTER_BREAK


"J.T. Conklin" wrote:

Anything, anything.  Just as long as DECR_PC_AFTER_BREAK is eleminated
from the high level code :-)

	Andrew

> 
> A month or two ago, a user on bug-gdb mentioned that he had to modify
> the m68k stub to decrement the PC for breakpoint exceptions.  I spent
> some time then investigating, but never got a round to bringing this
> issue up here.
> 
> For a very long time, perhaps forever, the m68k embedded targets have
> set DECR_PC_AFTER_BREAK to 0 even though the m68k architecture itself
> increments the PC after a breakpoint insn.  This works because all of
> the ROM monitors we support decrement the PC (fwiw, I suspect that any
> monitor we don't support will do this too.  Any other behavior would
> be too confusing to human operators).
> 
> The problem arises because the sample stub does not make the same
> adjustment.  I responded to the user that his change to adjust the PC
> if the vector is a breakpoint exeception seemed to be the right thing
> to do.  Thoughts?  If there are no objects, I'll submit such a patch
> in my next round of stub maintenance.
> 
> Having DECR_PC_AFTER_BREAK set to 0 on embedded targets that only use
> the remote protocol has another advantage that it reduces the single-
> step overhead.  If DECR_PC_AFTER_BREAK != 0, GDB must fetch the PC,
> decrement it, and store it after each step returns.  This is
> especially painful if the stub doesn't implement the 'P' command (set
> single register) or the 'T' response to the execution commands,
> because GDB must then fetch and store the entire register set.
> 
> In fact, from time to time I've thought about what it would take to
> make GDB's iX86 embedded targets use DECR_PC_AFTER_BREAK == 0 even
> though we're not supporting ROM monitors that would require it (As
> above, I suspect if we went searching for iX86 ROM monitors, they
> would be like the m68k monitors).  I'm not sure if that would require
> additional targets to support firmware with old stubs or mechanism to
> change the value of DECR_PC_AFTER_BREAK while GDB is running.
> 
>         --jtc
> 
> --
> J.T. Conklin
> RedBack Networks

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