[PATCH] Wrong page protection flags on FreeBSD/PPC
Krzysztof Parzyszek
kparzysz at codeaurora.org
Wed Feb 20 10:06:31 PST 2013
On 2/20/2013 11:55 AM, Hal Finkel wrote:
>
> It is fine by me. I don't know why FreeBSD and Linux differ here, but I suppose this is an empirical matter. Please feel free to commit. Is there a reason that we don't want to remove read permission after the flush?
I was thinking about it. I considered temporarily adding PROT_READ
flag, then flushing the cache, and then removing it. This would have to
happen inside "Memory::InvalidateInstructionCache", because it is an
external function. The problem is that if mprotect was to fail for any
reason, we would be unable to actually invalidate the cache (or to
remove the PROT_READ flag afterwards), and there is no way to indicate
such a failure to the caller. If we control the function that
translates user-level protection flags to OS-specific flags, we could
ensure that PROT_READ is always present when PROT_EXEC was requested.
It may not be very elegant, but it should be safe.
-Krzysztof
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
More information about the llvm-commits
mailing list