Re: remote software breakpoint technical detail

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Tzu-Chien" == Tzu-Chien Chiu <tzuchien.chiu@gmail.com> writes:

 Tzu-Chien> Hi, all. I'm new to gdb. I have a question on the remote
 Tzu-Chien> software breakpoint implementation. Either my porting of
 Tzu-Chien> gdb or there is a bug in our hardware implementation.

 Tzu-Chien> We have an OpenRISC silicon
 Tzu-Chien> (http://www.opencores.org). I'm using GDB 5.0.

 Tzu-Chien> Suppose the instruction cache has been disabled in the
 Tzu-Chien> very beginning.

 Tzu-Chien> Here is what I observed: 1) the user set a breakpoint
 Tzu-Chien> ('b') at instruction foo 2) the user continue ('c') the
 Tzu-Chien> execution 3) gdb replaces instruction foo with a
 Tzu-Chien> 'breakpoint instruction", which will stall the processor
 Tzu-Chien> 4) gdb unstall the processor 5) the processor fetches the
 Tzu-Chien> breakpoint instruction into the execution pipeline, and
 Tzu-Chien> point pc to the next instruction 6) the breakpoint
 Tzu-Chien> instruction is decoded, recognized, and the processor
 Tzu-Chien> stalls 7) gdb restores instruction foo 8) the user issues
 Tzu-Chien> the single instruction step ('si'), and he expects
 Tzu-Chien> instruction foo be executed next, but...

 Tzu-Chien> The question is:

 Tzu-Chien> What value of pc should be expected after step 5
 Tzu-Chien> completes?

 Tzu-Chien> if $pc==foo+4, foo won't be executed but the following
 Tzu-Chien> instruction, which is incorrect.

 Tzu-Chien> if $pc==foo, the breakpoint instruction _has been_ fetched
 Tzu-Chien> into the execution pipeline at step 5, what makes the cpu
 Tzu-Chien> to *fetch again* the instruction restored by gdb at step
 Tzu-Chien> 7? GDB or the hardware must be designed to do so?

The target dependent code in GDB can deal with either foo+4 or foo.
Look at the documentation (in gdbint) for DECR_PC_AFTER_BREAK.

When GDB tells the target to write to memory (for example, as part of
setting or clearing a breakpoint) the target stub, or the target OS,
is responsible for dealing with caches, pipelines, etc.  

For example, most modern machines have separate I and D caches, and
I-fetching doesn't look in the D-cache.  So a memory write does
roughly the following:
1. Store the data
2. Flush the D-cache (forcing all pending writes, or perhaps just the
   address modified in step 1, to memory)
3. Invalidate the I-cache (forcing I-fetches to go to memory instead).

If your processor has a fetch pipeline, and it doesn't re-fetch the
instruction at "foo" unless told to do so, then you (the target side
code) have to tell it to do that.

      paul