Add an IS_SCRATCH flag to mark scratch memory with.

[khuey]

Fixes #3779

[khuey]

I'm not entirely convinced this is sufficient. In #3779 it was reported that two scratch memory segments ended up being adjacent to each other. The reporter claims this patch fixes his issue. But it's not clear to me that this actually prevents coalescing adjacent scratch maps in all circumstances. is_coalescable() checks that the two flags are equal to each other (

rr/src/AddressSpace.cc

Line 2062 in e293422

return mleft.flags == mright.flags;

) but other comments suggest that mappings with flags should never be coalesced (

rr/src/AddressSpace.cc

Line 1706 in e293422

ASSERT(t, !mapping.flags);

). Is there something I'm missing that prevents maps from being merged when is_coalescable() is true? Or is the reporter just getting lucky with their test case.

[rocallahan]

Is there something I'm missing that prevents maps from being merged when is_coalescable() is true?

I don't think you're missing anything.

What if we fix this a different way? In inject_handled_signal() we could grab the current contents of the memory where the sigframe is going to appear, and then we could diff it against the memory after the singlestep has caused the kernel to write the sigframe. Then we can record only the changed range.

I think that would solve our replay issues, but ... what if the kernel actually uses the scratch mapping to store part of the sigframe? I don't think there's anything preventing that from happening, right? Which suggests we actually need a real guard page to stop that.