<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 5, 2015 at 8:16 PM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@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 May 5, 2015, at 8:12 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br><div><br><br style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Tue, May 5, 2015 at 4:04 PM, Adrian Prantl<span> </span><span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>> On May 1, 2015, at 2:18 PM, Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br>><br>><br>>> On May 1, 2015, at 2:00 PM, Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>> wrote:<br>>><br>>>> A few more things that vote for debugger tuning:<br>>>><br>>>> - LLDB doesn't like to have DWARF that has a class A that inherits from<br>>>> class B, but only a forward declaration of class B is provided.<br>>><br>>> Hmm do we emit that kind of thing today?  In a naïve test, I'm seeing<br>>> the full description of class B.<br>><br>> by default for darwin, it doesn't do this. For others you must specify -fno-limit-debug-info or some flag like that.<br><br></span>I think the option is -f(no-)standalone-debug-info</blockquote><div><br>-fno-limit-debug-info == -fstandalone-debug<br>(limit-debug-info was the old name & we had a long discussion and decided standalone-debug more aptly described what it should mean/how it should generalize)<br></div></div></div></blockquote><div><br></div></span>And if my memory serves correctly, what adds to the confusion is that -flimit-debug-info used to do more than just this particular optimization, but we decided that most of the other optimizations weren’t really helpful, so they were removed.</div></div></blockquote><div><br>Not quite - I refactored the existing optimizations once I figured out what they did & how it generalized, they are still controlled by the same (both) flags. There are 3 main optimizations:<br><br>1) requires complete type (if a type is referenced, use a declaration unless the type is required to be complete (eg: it was dereferenced somewhere, etc))<br>2) vtable (if a type is dynamic, only emit its definition where the vtable is emitted)<br>3) explicit template instantiation (if a type has an explicit template instantiation declaration, only emit the definition where the explicit template instantiation definition is)<br><br>I really should write a blog post about all this. Seems to create endless confusion. (so far as I know, GCC only does (2), perhaps it does some other things that we don't do, but I haven't seen it)<br> </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><div><div class="h5"><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">which only emits full definitions of classes in the object file that holds and object’s vtable.<br><span><font color="#888888"><br>-- adrian<br></font></span><div><div>><br>>>> - LLDB wants the .apple_XXX accelerator tables, GDB wants<br>>>> .debug_pubnames/.debug_pubtypes<br>>><br>>> Agreed.<br>>><br>>>> So it would be great to have a "-debugger" flag that could be specified<br>>>><br>>>> -debugger=lldb<br>>>> -debugger=gdb<br>>>><br>>>> Not sure on the option name, but I do like the idea.<br>>><br>>> We'll bikeshed the name later but yes, that's the plan.<br>>> Thanks,<br>>> --paulr<br>>><br>>>><br>>>> Greg<br>>>><br>>>>> On May 1, 2015, at 1:06 PM, Robinson, Paul<br>>>> <<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>> wrote:<br>>>>><br>>>>> This is basically a reboot of the previous thread titled<br>>>>> About the "debugger target"<br>>>>> except that "target" was really too strong a term for what I had<br>>>> intended<br>>>>> to use this feature for.  "Debugger tuning" is more like it.  You don't<br>>>>> need to have read the previous thread, I'll recap here.<br>>>>><br>>>>> Fundamentally, Clang/LLVM uses DWARF as the specification for the<br>>>> _format_<br>>>>> of information provided by the compiler to a variety of "consumers,"<br>>>> which<br>>>>> primarily means debuggers (but not exclusively).  [For a long time it<br>>>> was<br>>>>> the only format supported by LLVM. Lately, Microsoft debug info has<br>>>> started<br>>>>> appearing, but being a less widely used format, the issues that DWARF<br>>>> runs<br>>>>> into aren't a concern for that format.  So "debugger tuning" is unlikely<br>>>>> to be an issue for Microsoft debug info.]<br>>>>><br>>>>> DWARF is a permissive standard, meaning that it does not rigidly require<br>>>>> that source-language construct X must be described using the DWARF<br>>>>> construct Y.  Instead, DWARF says something more like, "If you have a<br>>>>> source construct that means something like X, here's a mechanism Y that<br>>>>> you could use to describe it."  While this gives compilers a lot of nice<br>>>>> flexibility, it does mean that there's a lot of wiggle room for how a<br>>>>> compiler describes something and in how a debugger interprets that<br>>>>> description.  Compilers and debuggers therefore need to do a bit of<br>>>>> negotiation in determining how the debug-info "contract" will work, when<br>>>>> it comes to nitty-gritty details.  DWARF itself (the standard, as well<br>>>>> as the committee that owns the standard) refuses to get involved in this<br>>>>> negotiation, referring to all that as "quality of implementation<br>>>> issues."<br>>>>><br>>>>> It is readily apparent that different debuggers have different ideas<br>>>>> about certain DWARF features, for example whether they are useful or<br>>>>> irrelevant, or whether a certain source construct should be described<br>>>>> this way or that way.  As these generally fall into the QOI realm, the<br>>>>> DWARF spec itself is no help, and it comes down to a matter of opinion<br>>>>> about whether "the debugger should just know this" or "the compiler<br>>>>> really ought to just emit it that way."<br>>>>><br>>>>> Clang/LLVM is in the position of being a compiler that wants to support<br>>>>> several different debuggers, all of which have slightly different ideas<br>>>>> about what they want from the DWARF info for a program.  Our first line<br>>>>> of defense of course is the DWARF standard itself, but as we've seen,<br>>>>> that is not a universally definitive reference.<br>>>>><br>>>>> LLVM already emits DWARF slightly differently for different *targets*;<br>>>>> primarily Darwin, in a few cases PS4.  But in at least some cases, the<br>>>>> target is just a (somewhat unreliable) proxy for which *debugger* the<br>>>>> compiler expects to be consuming the DWARF.  The most instructive case<br>>>>> is the exact DWARF expression used to describe the location of a thread-<br>>>>> local variable.  DWARF v3 defined an operator to find the base address<br>>>>> of the thread-local storage area; however, GDB has never learned to<br>>>>> recognize it.  Therefore, for targets where we "know" GDB isn't used,<br>>>>> we can emit the standard operator; for targets where GDB *might* be<br>>>>> used, we need to emit the equivalent (non-standard) GNU operator.<br>>>>><br>>>>> It would be semantically more meaningful to base decisions like this on<br>>>>> whether we expected the debugger to be X or Y or Z.  Therefore I've<br>>>>> proposed (<a href="http://reviews.llvm.org/D8506" target="_blank">http://reviews.llvm.org/D8506</a>) a "debugger tuning" option that<br>>>>> will make the reasoning behind these choices more obvious, and<br>>>> ultimately<br>>>>> give users a way to control the tuning themselves, when the platform's<br>>>>> default isn't what they want. (I'll have a follow-up patch exposing the<br>>>>> tuning option to the Clang driver.)<br>>>>><br>>>>> So, what kinds of things should be based on the debugger tuning option?<br>>>>> Are there still things that should be based on the target platform?<br>>>>> Simplest to consider these questions together, because it is often clear<br>>>>> which criterion is important if you consider (a) the same debugger run<br>>>>> on different targets, versus (b) different debuggers running on the same<br>>>>> target.  Basically, if the same debugger on different targets wants to<br>>>>> have something a certain way, that's probably a debugger-tuning thing.<br>>>>> And if different debuggers on the same target doesn't mean you should<br>>>>> change how the DWARF looks, that's likely a platform-specific thing.<br>>>>><br>>>>> The most obvious example of a debugger-tuning consideration is the TLS<br>>>>> operator mentioned above. That's something that GDB insists on having.<br>>>>> (It turns out that the standard operator was defined in DWARF 3, so we<br>>>>> also have to emit the GNU operator if we're producing DWARF 2.  Tuning<br>>>>> considerations don't trump what the standard says.)<br>>>>><br>>>>> Another example would be .debug_pubnames and .debug_pubtypes sections.<br>>>>> Currently these default to omitted for Darwin and PS4, but included<br>>>>> everywhere else. My initial patch for "tuning" changes the PS4 platform<br>>>>> criterion to the SCE debugger predicate; quite likely the "not Darwin"<br>>>>> criterion ought to be "not LLDB" or in other words "on for GDB only."<br>>>>> And having the code actually reflect the correct semantic purpose seems<br>>>>> like an overall goodness.<br>>>>><br>>>>> An example of a target-dependent feature might be the .debug_aranges<br>>>>> section. As it happens, we don't emit this section by default, because<br>>>>> apparently no debugger finds it useful, although there's a command-line<br>>>>> option (-gdwarf-aranges) for it.  But, for PS4 we do want to emit it,<br>>>>> because we have non-debugger tools that find it useful.  We haven't yet<br>>>>> done the work to make that change on<span> </span><a href="http://llvm.org/" target="_blank">llvm.org</a>, but it's on the list.<br>>>>> I would conditionalize this on the target, not the debugger, because<br>>>>> the debugger is not why we want to generate the section.<br>>>>><br>>>>> Okay, so I've been pretty long-winded about all this, can I possibly<br>>>>> codify it all into a reasonably succinct set of guidelines?  (which<br>>>>> ought to be committed to the repo somewhere, although whether it's as<br>>>>> a lump of text in a docs webpage or a lump of commentary in some source<br>>>>> file is not clear; opinions welcome.)<br>>>>><br>>>>> o Emit standard DWARF if possible.<br>>>>> o Omitting standard DWARF features that nobody uses is fine.<br>>>>> (example: DW_AT_sibling)<br>>>>> o Extensions are okay, but think about the circumstances where they<br>>>>> would be useful (versus just wasting space).  These are probably a<br>>>>> debugger tuning decision, but might be a target-based decision.<br>>>>> (example: DW_AT_APPLE_* attributes)<br>>>>> o If some debugger can't tolerate some piece of standard DWARF, that's<br>>>>> a missing feature or a bug in the debugger.  Accommodating that in<br>>>>> the compiler is a debugger tuning decision.<br>>>>> (example: DW_OP_form_tls_address not understood by GDB)<br>>>>> o If some debugger has no use for some piece of standard DWARF, and<br>>>>> it saves space to omit it, that's a debugger tuning decision.<br>>>>> (example: .debug_pubnames/.debug_pubtypes sections)<br>>>>> o If a debugger wants things a certain way regardless of the target,<br>>>>> that's probably a debugger tuning decision.<br>>>>> o If "system" software on a target (other than the debugger) wants<br>>>>> things a certain way regardless of which debugger you're using,<br>>>>> that's NOT a debugger tuning decision, but a target-based decision.<br>>>>> (example: .debug_aranges section)<br>>>>><br>>>>> Let me know if this all seems reasonable, and especially if you have<br>>>>> a good idea where to keep the guidelines.<br>>>>> Thanks,<br>>>>> --paulr<br>>>>><br>>>>><br>>>>> _______________________________________________<br>>>>> lldb-dev mailing list<br>>>>><span> </span><a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>>>>><span> </span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>>><br>><br>><br>> _______________________________________________<br>> LLVM Developers mailing list<br>><span> </span><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>><span> </span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br><br><br></div></div><div><div>_______________________________________________<br>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></div></div></blockquote></div></div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>