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