<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 11, 2014 at 3:00 PM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:kyrtzidis@apple.com" target="_blank">kyrtzidis@apple.com</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"><br><div><span class=""><blockquote type="cite"><div>On Dec 11, 2014, at 2:59 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 11, 2014 at 2:40 PM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:kyrtzidis@apple.com" target="_blank">kyrtzidis@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The .pcm file is currently independent of debug info, meaning the compiler invocation will be able to use the same .pcm file regardless of whether the invocation had enabled debug info or not;</blockquote><div><br></div><div>We can't use the same .pcm file for -DNDEBUG vs -UNDEBUG builds. Do we ever get to reuse a .pcm file like this in practice?</div></div></div></div></div></blockquote><div><br></div></span><div>You can choose to add, or not to add, debug info to a release build.</div></div></div></blockquote><div><br></div><div>Sure, I don't dispute that this .pcm reuse can happen in theory. But what I'm wondering is: Does this actually happen in practice? How often? Is this case worth optimizing for?</div><div><br></div><div>There are other things I'd like to bundle with a .pcm file (.o and .ir code for inline functions, for instance) that would also benefit from using an ELF wrapper format, and would also vary based on clang's CodeGen options. One possible approach would be to have (at least) two files -- one CodeGen-independent AST file, and one CodeGen-dependent file containing all the other bits -- but that seems to introduce complexity that is unnecessary in almost all cases. (Also note that even flags like -O or -fsanitize=address cause us to build different .pcm files today, because they affect preprocessor macros.)</div><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><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">with this change if an invocation had built a module file with debug info disabled, it would be inapplicable to the same invocation that had debug info enabled and would have to rebuild it; essentially we are tying module building with debug info. The module file as the “collection of semantic info” is conceptually independent from debug info.<br>
<br>
Did you consider having the debug info container being another file (e.g. besides the .pcm) that will reference the .pcm file ? This way, instead of having to update all users of module files, regardless if they care about debug info or not, you’d just make debug info another user of .pcm files, no more special than the others.<br>
<div><div><br>
> On Dec 10, 2014, at 2:27 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<br>
><br>
> Hi everyone,<br>
><br>
> As the first step in preparation for module debugging (see <a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-November/040076.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-November/040076.html</a>) this patch turns the *.pcm files that are used to store clang modules and precompiled headers in a platform-dependent Mach-O/ELF/COFF container, so that eventually we will be able to store debug information alongside the module in the same file.<br>
><br>
> This is implemented by using the standard LLVM code generation machinery. Instead of directly writing to the output file, the serialized AST blob is attached to an empty llvm::Module as a ModuleFlag. The module is passed to the backend which emits the AST blob into a special “__clang_pch" section in TargetLoweringObjectFile*.<br>
> On the ASTReader side, any object file is transparently unwrapped and the BitstreamReader is pointed directly to the AST section.<br>
><br>
> Other than the .pcm files having an extra header inside, this patch is not meant to have any user-visible effects.<br>
><br>
> Known bugs: I still need to figure out how to make c-index-test link against and register the available targets (check-all passes, but the modules created by c-index-test currently are plain old .pcm files).<br>
> Open questions: I made up the name of the new __clang_pch section and the various flags on the different platforms on the spot. I’m open to better suggestions.<br>
><br>
> Let me know what you think!<br>
><br>
> -- adrian<br>
</div></div>> <clang.diff><llvm.diff>_______________________________________________<br>
<div><div>> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
</div></div></blockquote></div><br></div></div>
</div></blockquote></span></div><br></div></blockquote></div><br></div></div>