We call InvalidateInstructionCache() twice here and I think the second call is just wasted work. Hopefully my guess is correct.
Details
Diff Detail
Event Timeline
lib/Support/Unix/Memory.inc | ||
---|---|---|
266–282 | Whatever we do here should be consistent for all platforms. I haven't taken a good look at the icache invalidation code - I'll have a think about this tomorrow. |
Lang, what are your thoughts about this?
Should we invalidate the cache unconditionally instead?
Thanks!
Hi Davide,
I spoke with Jim Grosbach about this and we agreed that 'setExecutable' should do everything required to make the memory executable on the host processor. That means unconditionally setting the permissions and invalidating the icache (on processors that need that). The problem is with clients who call InvalidateInstructionCache after calling setExecutable: that should be redundant. Clients should either call setExecutable alone, or call both protectMappedMemory and InvalidateInstructionCache manually.
So - we should remove the redundant calls, and modify setExecutable where necessary to properly set the permissions.
LGTM, pending the removal of the icache invalidation for the data sections.
tools/llvm-rtdyld/llvm-rtdyld.cpp | ||
---|---|---|
393 | The instruction cache doesn't need to be invalidated for data sections, so this loop should be removed. |
Whatever we do here should be consistent for all platforms. I haven't taken a good look at the icache invalidation code - I'll have a think about this tomorrow.