gdb requires watchpoints to fire after the write

[Simon Marchi]

On 2018-08-29 11:47, Joel Brobecker wrote:
>> 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).
> 
> I seem to remember some architectures having different behaviors,
> and so we have a couple of entry points in GDB. For 
> architecture-specific
> settings, we have gdbarch_have_nonsteppable_watchpoint. For 
> target-specific
> settings, you would use target_have_steppable_watchpoint. (IIRC)

Indeed, the comment at infrun.c:5805 seems to hint that some (or all?) 
targets/arches do work like that?  And the fix is that GDB does a single 
step to execute the instruction that modifies the memory, and then 
evaluates the expression.  I hadn't thought about that.

See: 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/infrun.c;h=7731ccda68343b0118b9806615ff45b9f4d56c63;hb=HEAD#l5805

I'm just confused by this condition:

   if (stopped_by_watchpoint
       && (target_have_steppable_watchpoint
	  || gdbarch_have_nonsteppable_watchpoint (gdbarch)))

I don't understand why we check for target_have_steppable_watchpoint OR 
gdbarch_have_nonsteppable_watchpoint, they seem to mean opposite things.

Simon