On Tue, May 30, 2017 at 11:08 AM, Keno Fischer <[email protected]> wrote: > Now, while we're probably fine with using the fallbacks, I know there's > others that rely on this behavior as well (cc'ing Robert O'Callahan of the > rr project for which this change will result in significant performance > degradation).
Yeah, this breaks rr. We write to readonly code and data mappings via /proc/.../mem in lots of different situations, particularly when we're adjusting program state during replay to match the recorded execution. Like Julia, we can add workarounds, but they could be expensive. For small writes we can fall back to PTRACE_POKEDATA without much performance loss, but for big writes it would be cheaper to sock-puppet the ptracee to call mprotect to temporarily make pages writeable. Of course that takes at least four context switches, so the lower-bound overhead of that approach is pretty bad. OTOH there are probably tricks we could pull to mitigate the overhead some more. For example during replay we might be able to make some pages that "should" be read-only actually be read-write when we know the recorded process didn't try writing to them. So in summary: rr can be upgraded to cope with this, incurring some unknown amount of additional overhead, but existing rr installs will definitely be totally broken. Thanks, Rob
