gdb requires watchpoints to fire after the write

[Simon Marchi]

On 2018-08-28 18:08, Tim Newsome wrote:
> The RISC-V Debug Spec suggests that memory write triggers fire before 
> the
> access actually takes place. This allows a user to see what the value 
> in
> memory is before it's overwritten. This does not play nice with gdb's
> watchpoint expectation, however. When a watchpoint is hit, gdb 
> instantly
> reads the memory that it fired on, and if it hasn't changed it silently
> lets execution resume. Since on RISC-V the watchpoint fired before the
> write actually took place, gdb will always miss the first write because
> memory won't have changed yet.
> 
> Does that sound right? How should I fix this? With hardware breakpoint
> functionality being generally all over the map, I can't imagine this 
> hasn't
> come up before.

I don't have experience with many different architectures, but as far as 
I know, the expectation of the GDB is that the watchpoint is reported 
after the write.  Otherwise it wouldn't need to save the value of the 
watched expression.  That's also how software watchpoints seem to work.

The easiest way to deal with this would be to match GDB's expectation.  
But if you really prefer the behavior of reporting the watchpoint before 
the event, I suppose it's always possible to teach GDB about this, but 
it's a less trivial task.  Especially that when you GDB evaluates 
whether the watch expression has changed value, it would need to 
consider the not-yet-written value in memory.

I'm also curious to know if other architectures work in this way (report 
the event before the write actually take place).

Simon