<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Zachary,<div class=""><br class=""></div><div class="">I will be happy to roll-back/fix whatever parts of this break builds. I don’t see how a review period will make this easier, except by adding an extra dependency on someone else applying the patches and getting back to me.</div><div class=""><br class=""></div><div class="">Sean</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 4, 2014, at 5:18 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Would it be possible to put patches up for review for at least a couple days BEFORE comitting? There's a pretty good chance this will break a build somewhere, and an average chance that the break won't be that easy to fix. And having broken builds for a couple of days doesn't seem reasonable.<br class=""><br class="">Im not sure how thoroughly we can review it, but at least we can prevent broken builds this way.<br class=""><div class="gmail_quote">On Thu, Dec 4, 2014 at 5:10 PM Sean Callanan <<a href="mailto:scallanan@apple.com" class="">scallanan@apple.com</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><b class="">Rationale</b></div><div class=""><br class=""></div>A historical pain point in the expression parser has been using functions for which the type is not completely known from debug information.<div class="">This is the case e.g. for functions from the C standard library, and also for Objective-C methods in frameworks.</div><div class="">It’s also unfortunate when handy types, enums, etc. are invisible just because your DWARF doesn’t happen to contain them.</div><div class="">I’m doing something about that, for OS X – but it should generalize to other platforms.</div><div class=""><br class=""></div><div class=""><b class="">Clang modules: the basics</b></div><div class=""><br class=""></div><div class="">The code I’m about to commit adds support for Clang modules to the expression parser. Clang modules are described in much more detail here:</div><div class=""><span style="white-space:pre-wrap" class=""> </span><a href="http://clang.llvm.org/docs/Modules.html" target="_blank" class="">http://clang.llvm.org/docs/Modules.html</a> </div><div class="">but here is a short introduction:</div><div class=""><br class=""></div><div class="">A group of header files is encapsulated in a module, which is provided with a module.map file.</div><div class="">On OS X, this module.map is typically inside the corresponding framework.</div><div class="">Clang reads module.map and the corresponding headers and produces a compiled module. </div><div class="">This compiled module is essentially a .pch; it provides full information about all APIs, types, etc. defined in the module.</div><div class=""><br class=""></div><div class=""><b class="">LLDB support</b></div><div class=""><b class=""><br class=""></b></div><div class="">In order to use Clang modules, LLDB must:</div><div class=""><br class=""></div><div class=""><ol class=""><li class="">Know where they live (from Clang’s perspective, this is the “sysroot”) and what compilation flags to use when parsing them;</li><li class="">Know which ones the user wants;</li><li class="">Compile them with its built-in Clang instance; and</li><li class="">Use the information found in the compiled modules as appropriate.<br class=""><br class=""></li></ol></div><div class="">LLDB accomplishes each of these goals in the following ways:</div><div class=""><br class=""></div><div class=""><ol class=""><li class="">Platforms can now return the appropriate Clang flags that tell the module importer where to find modules for the current platform. Explicit support is enabled in PlatformDarwin. Other platforms can opt into this by returning true from Platform::SupportsModules() and adding the appropriate compilation options when Platform::AddClangModuleCompilationOptions() is called. If they return false, there should be no change in behavior.</li><li class="">LLDB adds preprocessor callbacks to Clang that catch @import directives. When such a directive is found, LLDB directs its built-in Clang to import the named module.</li><li class="">Modules are imported into a separate compiler instance (with its own AST context) encapsulated in ClangModulesDeclVendor so that we can be careful about what we actually import into expressions. Information in DWARF will often take precedence, for instance.</li><li class="">ClangExpressionDeclMap – the code responsible for finding entities Clang asks about while it parses expressions – is being extended to load information from modules as appropriate. The initial commit simply searches for functions (e.g., printf()) but I will be adding functionality rapidly.<br class=""><br class=""></li></ol></div><div class=""><b class="">What the upcoming patches do</b></div><div class=""><b class=""><br class=""></b></div><div class=""><ul class=""><li class="">ClangModulesDeclVendor.h/.cpp implements the portions of LLDB responsible for driving the modules compiler. This should be platform-generic code, although in practice we may need to tweak it to make sure it is flexible enough to handle everything.</li><li class="">TypeVendor has been changed to DeclVendor, so that the Objective-C runtime can share the same method signatures with the Clang module importer. Places that used TypeVendor now use DeclVendor, and I’ve tweaked the APIs for getting types from decls to make this transition smooth.</li><li class="">Platform (as mentioned above) now can return the flags necessary to tell Clang where modules live. PlatformDarwin has a bunch of new code to find these; I also have a default implementation that you can try out if you want, but unless you know what a module.map is I would hold off on this.</li><li class="">The LLDB bundle on Mac OS X will now also include the compiler-specific headers Clang requires to compile standard library headers (e.g., tgmath.h, stdarg.h). Host can find the location of these headers; on non-OS X hosts, we’ll need to put them in some sensible place.</li><li class="">ClangExpressionParser.cpp now sets up the appropriate context to intercept @import directives.</li><li class="">ClangExpressionDeclMap.cpp now searches modules (if available) for functions if it doesn’t find them in DWARF.</li><li class="">Targets now vend their ClangModulesDeclVendors as appropriate.</li></ul><div class=""><br class=""></div></div><div class=""><b class="">Timeline and priorities</b></div><div class=""><b class=""><br class=""></b></div><div class="">I’m going to start committing <i class="">today</i>, but if any of these commits breaks anything for you, please let me know.</div><div class="">My priority is getting this working on OS X first. If parts of my code look platform-myopic, please let me know, though – I really want to see debugging with modules working on other platforms too.</div><div class="">Of course if any of this breaks any build, let me know immediately and I’ll get on it.</div></div>______________________________<u class=""></u>_________________<br class="">
lldb-dev mailing list<br class="">
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank" class="">lldb-dev@cs.uiuc.edu</a><br class="">
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank" class="">http://lists.cs.uiuc.edu/<u class=""></u>mailman/listinfo/lldb-dev</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>