<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 25, 2016, at 3:24 AM, Jonas Devlieghere <<a href="mailto:jonas@devlieghere.com" class="">jonas@devlieghere.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi,<br class=""><br class="">I hope I'm not breaking any mailing list etiquette by replying to this<br class="">mail, but if I am then please accept my apologies.<br class=""><br class="">On Fri, Jun 3, 2016 at 8:36 PM, Steven Wu via llvm-dev<br class=""><<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""><blockquote type="cite" class="">Hi everyone<br class=""><br class="">I am still in the process of upstreaming some improvements to the embed<br class="">bitcode option. If you want more background, you can read the previous RFC<br class="">(<a href="http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html" class="">http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html</a>). This<br class="">is part II of the discussion.<br class=""><br class="">Current Status:<br class="">A basic version of -fembed-bitcode option is upstreamed and functioning.<br class="">You can use -fembed-bitcode={off, all, bitcode, marker} option to control<br class="">what gets embedded in the final object file output:<br class="">off: default, nothing gets embedded.<br class="">all: optimized bitcode and command line options gets embedded in the object<br class="">file.<br class="">bitcode: only optimized bitcode is embedded<br class="">marker: only put a marker in the object file<br class=""><br class="">What needs to be improved:<br class="">1. Whitelist for command line options that can be used with bitcode:<br class="">Current trunk implementation embeds all the cc1 command line options (that<br class="">includes header include paths, warning flags and other front-end options) in<br class="">the command line section. That is lot of redundant information. To re-create<br class="">the object file from the embedded optimized bitcode, most of these options<br class="">are useless. On the other hand, they can leak information of the source<br class="">code. One solution will be keeping a list of all the options that can affect<br class="">code generation but not encoded in the bitcode. I have internally prototyped<br class="">with disallowing these options explicitly and allowed only the reminder of<br class="">the options to be embedded (<a href="http://reviews.llvm.org/D17394" class="">http://reviews.llvm.org/D17394</a>). A better<br class="">solution might be encoding that information in "Options.td" as specific<br class="">group.<br class=""><br class="">2. Assembly input handling:<br class="">This is a workaround to allow source code written in assembly to work with<br class="">"-fembed-bitcode" options. When compiling assembly source code with<br class="">"-fembed-bitcode", clang-as creates an empty section "__LLVM, __asm" in the<br class="">object file. That is just a way to distinguish object files compiled from<br class="">assembly source from those compiled from higher level source code but forgot<br class="">to use "-fembed-bitcode" options. Linker can use this section to diagnose if<br class="">"-fembed-bitcode" is consistently used on all the object files participated<br class="">in the linking.<br class=""><br class="">3. Bitcode symbol hiding:<br class="">There was some concerns for leaking source code information when using<br class="">bitcode feature. One approach to avoid the leak is to add a pass which<br class="">renames all the globals and metadata strings. The also keeps a reverse map<br class="">in case the original name needs to be recovered. The final bitcode should<br class="">contain no more symbols or debug info than a stripped binary. To make sure<br class="">modified bitcode can still be linked correctly, the renaming need to be<br class="">consistent across all bitcode participated in the linking and everything<br class="">that is external of the linkage unit need to be preserved. This means the<br class="">pass can only be run during the linking and requires some LTO api.<br class=""></blockquote><br class="">Regarding the symbol map, are you planning to upstream a pass that<br class="">restores the symbols? I have been trying to do this myself in order to<br class="">reverse the "BCSymbolMap". However this turned out to be less<br class="">straightforward than I'd hoped. Any info on this would be greatly<br class="">appreciated!</div></div></blockquote><div><br class=""></div>We have tools to restore symbols in the dSYM bundle (check dsymutil -symbol-map option in the Apple toolchain). </div><div>I don't think we have a pass to restore the symbols in the bitcode now but that should be very straight forward and I am happy to implement one as a part of the item 3. </div><div>Of course, that will only happen if the community thinks this feature is beneficial to them. At the meantime, if you need assist, please file a radar to Apple at <a href="https://bugreport.apple.com" class="">https://bugreport.apple.com</a>.</div><div><br class=""></div><div>Steven<br class=""><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">4. Debug info strip to line-tables pass:<br class="">As the name suggested, this pass strip down the full debug info to<br class="">line-tables only. This is also one of the steps we took to prevent the leak<br class="">of source code information in bitcode.<br class=""><br class="">Please let me know what do you think about the pieces above or if you have<br class="">any concerns about the methodology. I will put up patches for review soon.<br class=""><br class="">Thanks<br class=""><br class="">Steven<br class=""><br class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></blockquote><br class="">Cheers,<br class="">Jonas<br class=""></div></div></blockquote></div><br class=""></body></html>