I haven't looked at the whole thing yet, but any reason not to make this the default (other than it's slightly more complicated)?<div><br></div><div>-eric</div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Nov 6, 2012 at 8:01 AM, Thirumurthi, Ashok <span dir="ltr"><<a href="mailto:ashok.thirumurthi@intel.com" target="_blank">ashok.thirumurthi@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="color:#1f497d">Currently, RuntimeDyld clients (like MCJIT) cannot restrict the memory protection flags for sections that are read-only, RW or RX. Instead, all sections are loaded into RWX memory. This patch improves the interface
of RTDyldMemoryManager to allow sections to be allocated as RW and later protected as R, RW or RX. In addition, as RuntimeDyld clients may have multiple Modules to load, the interface includes a memory pool ID to pool allocations. This permits RuntimeDyld
clients to free a memory pool without impacting other loads. Finally, as RuntimeDyld loads a full Module, the RWX attributes of all sections are known prior to the first allocation. As a result, the interface includes the facility to log requests for memory.
The goal is to minimize the number of mmap/mprotect calls that must be made to load a Module, while also ensuring that no full page of memory is wasted.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">As RTDyldMemoryManager is a base class of JITMemoryManager, this patch touches all of the memory managers in the llvm code base.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">In addition, this patch provides two reference memory managers which can be committed separately. The first, a slightly modified version of SectionMemoryManager, is a trivial memory manager that happily ignores
the call to protectPool. This was previously ripped from lli.cpp and committed with tests in unittests/ExecutionEngine/MCJIT. This memory manager is useful for clients that are more interested in efficiency than security.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">MCJIT and JIT engines allow the client to specify a JITMemoryManager. Although this unifies the interface between execution engines, MCJIT clients use the methods in the base class RTDyldMemoryManager. SectionMemoryManager
also provides a convenient implementation of pure virtual methods in JITMemoryManager. In particular, SectionMemoryManager is now used by rt-dyld.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">Alternately, the SecureMemoryManager is a reference memory manager with an implementation of protectPool. This memory manager derives from SectionMemoryManager and provides a single class with functionality
of interest to MCJIT and RuntimeDyld clients. Specifically, requests with the same combination of RWX flags are satisfied by the same allocation. In addition, allocations can be grouped using a pool ID. The patch includes unit tests for all of this functionality.
In addition, this patch modifies lli to use the SecureMemoryManager.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">Looking forwards, options can be provided for lli and rt-dyld to choose between secure, fast, and remote memory managers. In addition, options can be provided for MCJIT to determine if protectPool will be called.
Finally, MCJIT can be reworked to support multiple Modules.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">While the patch is large, it has been provided for completeness to support reviews at the hackers workshop at llvm-dev. Reviewers on the list can restrict their comments to the interface or the implementation
as these can easily be performed in two separate commits. Thanks!<span class="HOEnZb"><font color="#888888"><u></u><u></u></font></span></span></p><span class="HOEnZb"><font color="#888888">
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p><u></u><span style="color:#1f497d"><span>-<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="color:#1f497d">Ashok Thirumurthi<u></u><u></u></span></p>
</font></span></div>
</div>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>