remote software breakpoint technical detail

remote software breakpoint technical detail

[Tzu-Chien Chiu]

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

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

Suppose the instruction cache has been disabled in the very beginning.

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

The question is:

What value of pc should be expected after step 5 completes?

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

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

--
Tzu-Chien Chiu - SMedia Technology Corp.
URL: http://www.csie.nctu.edu.tw/~jwchiu/

Re: remote software breakpoint technical detail

[Daniel Jacobowitz]

On Thu, May 04, 2006 at 01:43:07AM +0800, Tzu-Chien Chiu wrote:
> 5) the processor fetches the breakpoint instruction into the execution
> pipeline, and point pc to the next instruction
> 6) the breakpoint instruction is decoded, recognized, and the processor 
> stalls
> 7) gdb restores instruction foo
> 8) the user issues the single instruction step ('si'), and he expects
> instruction foo be executed next, but...
> 
> The question is:
> 
> What value of pc should be expected after step 5 completes?

The correct answer is "it depends".  In GDB, this is controlled by
"set_gdbarch_decr_pc_after_break", and most architectures use whichever
setting is more reasonable for their architecture.  For yours, it
sounds like you want to have GDB decrement the PC after breakpoints.
It will write to the PC register itself.

> if $pc==foo+4, foo won't be executed but the following instruction,
> which is incorrect.
> 
> if $pc==foo, the breakpoint instruction _has been_ fetched into the
> execution pipeline at step 5, what makes the cpu to *fetch again* the
> instruction restored by gdb at step 7? GDB or the hardware must be
> designed to do so?

This is an issue whether or not you decrement PC.  In the presence of
debugger modification of code, something must flush the pipeline.  I
am not familiar with how other targets do this; I suspect that whatever
is mediating between GDB and the target CPU is responsible (e.g. a
standalone JTAG box or an independent debug server running on the host).

-- 
Daniel Jacobowitz
CodeSourcery

Re: remote software breakpoint technical detail

[Paul Koning]

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