<div><span style="font-family:arial,sans-serif;font-size:13px">> But if you just want to see the code and the diff against upstream...</span><br></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div>
<div><font face="arial, sans-serif">If others are interested as well, here's all your changes via Github's "compare" feature:</font></div><div><font face="arial, sans-serif"><br></font></div><a href="https://mymail.qualcomm.com/owa/redir.aspx?C=yu3Jo4nVdU6kh1OLiSe-04bnBhWtps8IxTOCi0lWLdEE4UxDImiKxfAW68FhXG16blXtZLHc6Xs.&URL=https%3a%2f%2fgithub.com%2fgarious%2fllvm%2fcompare%2fmaster...chromium" target="_blank" style="font-family:Tahoma;font-size:13px">https://github.com/garious/llvm/compare/master...chromium</a><div>
<br></div><div>Fascinating stuff guys. What a great contribution.</div><div><br></div><div>-Greg<br><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 4, 2012 at 9:03 PM, Derek Schuff <span dir="ltr"><<a href="mailto:dschuff@google.com" target="_blank">dschuff@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Greg,<br>
Our repos are public already, hosted on the Chromium infrastructure.<br>
Our builds are based out of the Native Client repository. The nacl git<br>
mirror is at <a href="http://git.chromium.org/native_client/src/native_client.git" target="_blank">http://git.chromium.org/native_client/src/native_client.git</a><br>
(no gitweb, sorry). That repo has pointers to a bunch of other repos<br>
which make pnacl (LLVM, clang, binutils, and a few others. see the<br>
file pnacl/DEPS for more).<br>
But if you just want to see the code and the diff against upstream,<br>
our LLVM repo is in<br>
<a href="https://gerrit.chromium.org/gerrit/gitweb?p=native_client%2Fpnacl-llvm.git;a=shortlog;h=refs%2Fheads%2Fmaster" target="_blank">https://gerrit.chromium.org/gerrit/gitweb?p=native_client%2Fpnacl-llvm.git;a=shortlog;h=refs%2Fheads%2Fmaster</a><br>
All of our clang changes are upstream already.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Derek<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, Dec 4, 2012 at 5:23 PM, Greg Fitzgerald <<a href="mailto:garious@gmail.com">garious@gmail.com</a>> wrote:<br>
> Hi Eli,<br>
><br>
>> we are splitting the effort to manageable chunks that can<br>
>> be committed, tested and reviewed separately as<br>
>> independently as feasible<br>
><br>
> I'd be interested in experimenting with this stuff sooner than later. Could<br>
> you dump all the patches in a publicly accessible repo? How about Github?<br>
><br>
> Thanks,<br>
> Greg<br>
><br>
><br>
><br>
> On Tue, Dec 4, 2012 at 3:53 PM, Eli Bendersky <<a href="mailto:eliben@google.com">eliben@google.com</a>> wrote:<br>
>><br>
>> 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>
>><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<br>
>> link]<br>
>> *<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>
><br>
><br>
><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>
><br>
</div></div></blockquote></div><br></div>