Re: [reverse/record] adjust_pc_after_break in reverse execution mode?

[Pedro Alves <pedro at codesourcery dot com>]

On Monday 20 October 2008 01:39:30, Michael Snyder wrote:
> See, the problem is that "adjust_pc_after_break" is assuming
> memory-breakpoint semantics, but Process Record/Replay actually
> implements hardware-breakpoint semantics. ÂIt watches the
> instruction-address "bus" and stops when the PC matches the
> address of a breakpoint.
> 
> I suspect this is probably a problem with other record/replay
> back-ends too, but I haven't confirmed it yet.
> 

But that is wrong.  If GDB is telling the target to insert
software breakpoints, and the target is accepting them, then
GDB assumes software breakpoints semantics for that particular
architecture.  That's the `target_insert_breakpoint' semantics
(native/remote, doesn't matter).

For remote, if the stub is accepting Z0, those breakpoint should behave
as memory breakpoints.  See from the manual:

"
`Z0,addr,length'
Insert (`Z0') or remove (`z0') a memory breakpoint at address addr of size length. 

`Z1,addr,length'
    Insert (`Z1') or remove (`z1') a hardware breakpoint at address addr of size length. 
    A hardware breakpoint is implemented using a mechanism that is not dependant on being able to modify the target's memory. 
"

Notice that adjust_pc_after_break does this:

  /* Check whether there actually is a *software breakpoint* inserted
     at that location.  */
  if (software_breakpoint_inserted_here_p (breakpoint_pc))
      ^^^^^^^^
    {

If the stub on a decr_pc_after_break arch lies to GDB, then, PC
adjustment will be broken, even in normal forward debugging.

I believe the correct thing for the target to do is to
report `PC + decr_pc_after_breakpoint' on forward (replay or normal forward)
breakpoint hits, if it is telling GDB that it succesfully
inserted a software breakpoint.

-- 
Pedro Alves