<div><span style="font-family:arial,sans-serif;font-size:13px">Hi Eli,</span></div><span style="font-family:arial,sans-serif;font-size:13px"><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div>> we are </span><span style="font-family:arial,sans-serif;font-size:13px">splitting the effort to manageable chunks that can</span><div>

<span style="font-family:arial,sans-serif;font-size:13px">> be committed, </span><span style="font-family:arial,sans-serif;font-size:13px">tested and reviewed separately as</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">> independently as feasible</span><br>

</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">I'd be interested in experimenting with this stuff sooner than later.  Could you dump all the patches in a publicly accessible repo?  How about Github?</span></div>

<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Thanks,</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Greg</span></div>

<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 4, 2012 at 3:53 PM, Eli Bendersky <span dir="ltr"><<a href="mailto:eliben@google.com" target="_blank">eliben@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
We (the Portable Native Client team) would like to start upstreaming<br>
our LLVM modifications which contain support for Software Fault<br>
Isolation (SFI) as required for sandboxing programs to run under<br>
Native Client. Since the "total patch size" is quite big, we are<br>
splitting the effort to manageable chunks that can be committed,<br>
tested and reviewed separately as independently as feasible.<br>
<br>
One of the first things we'd like to start with is support for aligned<br>
instruction bundles in MC (assembler) level. This support exists in<br>
gas since binutils version 2.23<br>
(<a href="http://sourceware.org/binutils/docs/as/Bundle-directives.html#Bundle-directives" target="_blank">http://sourceware.org/binutils/docs/as/Bundle-directives.html#Bundle-directives</a>).<br>
Succinctly, the initial proposal is to add the following directives:<br>
<br>
.bundle_align_mode <num><br>
.bundle_lock<br>
.bundle_unlock<br>
<br>
With the following semantics:<br>
<br>
When aligned instruction bundle mode ("bundling" in short) is enabled<br>
(.bundle_align_mode was encountered with an argument > 0, which is the<br>
power of 2 to which the bundle size is equal), single<br>
instructions and groups of instructions between .bundle_lock and<br>
.bundle_unlock directives cannot cross a bundle boundary.<br>
<br>
For example, consider the following:<br>
<br>
.bundle_align_mode 4<br>
mov1<br>
mov2<br>
mov3<br>
<br>
Assuming that each of the mov instructions is 7 bytes long and mov1 is<br>
aligned to a 16-byte boundary, two bytes of NOP padding will be<br>
inserted between mov2 and mov3 to make sure that mov3 does not cross a<br>
16-byte bundle boundary.<br>
<br>
A slightly modified example:<br>
<br>
.bundle_align_mode 4<br>
mov1<br>
.bundle_lock<br>
mov2<br>
mov3<br>
.bundle_unlock<br>
<br>
Here, since the bundle-locked sequence "mov2 mov3" cannot cross a<br>
bundle boundary, 9 bytes of NOP padding will be inserted between mov1<br>
and mov2.<br>
<br>
For information on how this ability is used for software fault<br>
isolation by Native Client, see the following resources:<br>
<br>
* <a href="http://src.chromium.org/viewvc/native_client/data/site/NaCl_SFI.pdf" target="_blank">http://src.chromium.org/viewvc/native_client/data/site/NaCl_SFI.pdf</a> [PDF link]<br>
* <a href="http://www.chromium.org/nativeclient/reference/arm-overview#TOC-The-Native-Client-Solution:-Bundles-" target="_blank">http://www.chromium.org/nativeclient/reference/arm-overview#TOC-The-Native-Client-Solution:-Bundles-</a><br>


* Other papers listed at<br>
<a href="http://www.chromium.org/nativeclient/reference/research-papers" target="_blank">http://www.chromium.org/nativeclient/reference/research-papers</a><br>
<br>
We want to start with this feature because it is self-contained in MC,<br>
makes LLVM more compatible with gas, level and can be easily tested.<br>
Future upstreaming efforts will be able to build upon this<br>
functionality.<br>
<br>
Any comments, ideas and suggestions are welcome.<br>
<br>
Eli<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>