Partial `mprotect` on executable memory about dynasm-rs HOT 2 CLOSED

It stands to reason that it is possible, but it'd require a complete redo of the assembler architecture to support it as this is handled in a dependency : | . Probably would need to keep a shadow copy of the map around in RW memory, track any changes made and then only edit the affected pages to get some semblance of efficiency.

But well, I can tell you mprotect doesn't bother flushing the I$, otherwise #50 wouldn't be a thing. That was my assumption at first as well but it was proven wrong. Then the only logical thing it could be doing is just sequentially editing the TLB entries of the entire buffer. 200us is still a lot for that though, 10MB should be only two thousand and something pages, and ARM's loose ordering shenanigans should allow it to just queue up all the edits and only then throw in a barrier so why is it taking .1 microsecond per page.

from dynasm-rs.

Thanks for the answer!

Yeah 0.1us per page is a lot and I'm not sure why either. Maybe it depends on the microarchitecture of the AArch64 implementation?

My use case is a RV64 -> AArch64 dynamic binary translator, and I'm patching the code to edit inline caches. I guess I should just put the caches outside the executable region for now :)

from dynasm-rs.