Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Monday 29 May 2017

Should Debuggers Report Idempotent Writes?

gdb's data watchpoints are designed to only trigger when a written value actually changes; i.e., writes to memory that leave the value unchanged are deliberately ignored. (rr has to follow gdb's behavior.) I don't know why gdb does this, but it may be for historical reasons: it's impractical for a normal debugger to observe all possible writes to memory (e.g. those performed by the kernel), so a traditional strategy for implementing watchpoints is simply to re-read the watched location frequently and report changes, and obviously this can't detect idempotent updates.

Over the last year Kyle Huey and I have been building a brand-new record-and-replay-based debugger. One of the most intellectually challenging aspects of this project is sorting through the decisions made by existing debuggers, distinguishing those which are truly desirable from those made under the duress of implementation constraints that no longer apply. Handling of idempotent writes is one such decision. During rr replay we can observe all memory writes, so reporting all idempotent writes is perfectly feasible.

There are some clear cases where idempotent writes should not be ignored. For example, consider a series of printfs repeatedly overwriting the contents an output buffer. If, at the end of the series, the user wants to understand how the final value of some byte in the buffer was obtained, we should report the last printf to write to that location, even if the byte value it happened to write was the same as that written to the location by some previous printf. Reporting the previous printf would be hopelessly confusing --- though this is, in fact, what rr+gdb do.

On the other hand, I'm cautious. There may be some good reason to ignore idempotent writes that we just haven't figured out yet. It could possibly involve optimization — an optimizing compiler is free to introduce spurious writes if it knows they'll be idempotent — but I haven't seen or thought of a plausible example where this would be a problem.

Comments

Nicholas
You have an example case where idempotent writes should be reported. You don't have clear cases where they should not be reported. Chesterton's Fence aside, the obvious/cautious approach would be to record them, but be prepared to re-evaluate this decision based on future experience.
Jeff Muizelaar
FWIW, here's a gdb bug I filed about this: https://sourceware.org/bugzilla/show_bug.cgi?id=19221. No one's posted a reason that it's a bad idea.
Anonymous
Other cases where idempotent writes should be reported are hardware registers where when reading you're getting register X and when writing you're using register Y. This is quite typical of IRQ status (reading)/clear (writing) registers. When writing, only the interrupts with a bit set when doing the write are cleared. This is to ensure that the clearing operation is atomic.
Unknown
I think ignoring them is plain wrong and a strange decision on the part of gdb. Maybe a long time a go redundant writes were more common (inside a single line of code/expression)? To explain what code is doing, showing each write to a variable or dynamically-allocated memory location makes the most sense. That is what the code does, after all... And for performance, lots of identical writes might be very interesting to see how the coed handles shared variables or locks or similar.