Displaying 3 results from an estimated 3 matches for "applymemorygrouppermiss".
2017 Jul 14
5
SectionMemoryManager::finalizeMemory ... read only data become executable?
Hi,
I am studying the llvm code and I noticed something that looks like a bug. If
it is intentional for some reason, it is not obvious why.
In lib/ExecutionEngine/SectionMemoryManager.cpp in
SectionMemoryManager::finalizeMemory method:
// Make code memory executable.
ec = applyMemoryGroupPermissions(CodeMem,
sys::Memory::MF_READ | sys::Memory::MF_EXEC);
...
// Make read-only data memory read-only.
ec = applyMemoryGroupPermissions(RODataMem,
sys::Memory::MF_READ | sys::Memory::MF_EXEC);...
2013 Nov 19
2
[LLVMdev] Some MCJIT benchmark numbers
...took about 12.6s, or 1.26ms per module, so
there's definitely some slowdown happening. Looking at the profiling
output, it looks like the main difference is the appearance of
MCJIT::finalizeLoadedModules(), which ultimately calls
RuntimeDyldImpl::resolveRelocations() and
SectionMemoryManager::applyMemoryGroupPermissions(), both of which iterate
over all memory sections leading to quadratic overhead. I'm not sure how
easy it would be, but it seems like there could be single-module variants
of these apis that could cut down on the overhead, since it looks like
MCJIT knows what modules need to be finalized b...
2013 Nov 19
0
[LLVMdev] Some MCJIT benchmark numbers
...6ms per module, so
> there's definitely some slowdown happening. Looking at the profiling
> output, it looks like the main difference is the appearance of
> MCJIT::finalizeLoadedModules(), which ultimately calls
> RuntimeDyldImpl::resolveRelocations() and
> SectionMemoryManager::applyMemoryGroupPermissions(), both of which iterate
> over all memory sections leading to quadratic overhead. I'm not sure how
> easy it would be, but it seems like there could be single-module variants
> of these apis that could cut down on the overhead, since it looks like
> MCJIT knows what modules ne...