<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 30 November 2016 at 15:46, Nico Weber via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Steven,<div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Jun 3, 2016 at 2:36 PM, Steven Wu via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi everyone<br><br>I am still in the process of upstreaming some improvements to the embed bitcode option. If you want more background, you can read the previous RFC (<a href="http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html" target="_blank">http://lists.llvm.org/piperma<wbr>il/llvm-dev/2016-February/<wbr>094851.html</a>). This is part II of the discussion. </div><div><br>Current Status:<br>A basic version of -fembed-bitcode option is upstreamed and functioning.<br>You can use -fembed-bitcode={off, all, bitcode, marker} option to control what gets embedded in the final object file output:<br>off: default, nothing gets embedded.<br>all: optimized bitcode and command line options gets embedded in the object file.<br>bitcode: only optimized bitcode is embedded<br>marker: only put a marker in the object file<br><br>What needs to be improved:<br>1. Whitelist for command line options that can be used with bitcode:<br>Current trunk implementation embeds all the cc1 command line options (that includes header include paths, warning flags and other front-end options) in the command line section. That is lot of redundant information. To re-create the object file from the embedded optimized bitcode, most of these options are useless. On the other hand, they can leak information of the source code. One solution will be keeping a list of all the options that can affect code generation but not encoded in the bitcode. I have internally prototyped with disallowing these options explicitly and allowed only the reminder of the  options to be embedded (<a href="http://reviews.llvm.org/D17394" target="_blank">http://reviews.llvm.org/D1739<wbr>4</a>). A better solution might be encoding that information in "Options.td" as specific group.<br><br>2. Assembly input handling:<br>This is a workaround to allow source code written in assembly to work with "-fembed-bitcode" options. When compiling assembly source code with "-fembed-bitcode", clang-as creates an empty section "__LLVM, __asm" in the object file. That is just a way to distinguish object files compiled from assembly source from those compiled from higher level source code but forgot to use "-fembed-bitcode" options. Linker can use this section to diagnose if "-fembed-bitcode" is consistently used on all the object files participated in the linking.<br></div></div></blockquote><div><br></div></span><div>It looks like shipping Xcode's clang has this behavior, but open-source clang still doesn't. Can you contribute it? It's very useful to us if open-source clang has the same features as the clang shipping in Xcode. (That last sentence is true in general, not just for this specific feature.)</div></div></div></div></blockquote><div><br></div><div>Just FYI, Steven is away on vacation for a month. I think he should be back in January.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div style="word-wrap:break-word"><div><br>3. Bitcode symbol hiding:<br>There was some concerns for leaking source code information when using bitcode feature. One approach to avoid the leak is to add a pass which renames all the globals and metadata strings. The also keeps a reverse map in case the original name needs to be recovered. The final bitcode should contain no more symbols or debug info than a stripped binary. To make sure modified bitcode can still be linked correctly, the renaming need to be consistent across all bitcode participated in the linking and everything that is external of the linkage unit need to be preserved. This means the pass can only be run during the linking and requires some LTO api.<br><br>4. Debug info strip to line-tables pass:<br>As the name suggested, this pass strip down the full debug info to line-tables only. This is also one of the steps we took to prevent the leak of source code information in bitcode.<br><br>Please let me know what do you think about the pieces above or if you have any concerns about the methodology. I will put up patches for review soon.<br><br>Thanks<span class="m_7560613489340444673HOEnZb"><font color="#888888"><br><br>Steven</font></span></div></div><br></span><span class="">______________________________<wbr>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-commits</a><br>
<br></span></blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div></div>