<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 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 _format_<br>
of information provided by the compiler to a variety of "consumers," which<br>
primarily means debuggers (but not exclusively).  [For a long time it was<br>
the only format supported by LLVM. Lately, Microsoft debug info has started<br>
appearing, but being a less widely used format, the issues that DWARF 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 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 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></blockquote><div><br>"not LLDB" wouldn't be "on for GDB only" (it'd be "on for GDB and SCE" given the current debuggers)<br><br>Eric, Adrian, and I hit another case of positive/negative checking recently for some DWARF feature... local anonymous unions. GDB likes to have explicit (possibly artificial) local variables for the unions members, LLDB can manage without them.<br><br>Eric & I discussed that there's a bit of a sliding scale of compatibility we should bother with - how much LLVM bends over backwards to cope with debugger bugs/limitations. I was inclined to just say it's a debugger bug and only enable the workaround when targeting that debugger specifically, and Eric wasn't. We came to the conclusion/agreement that maybe having it on by defaut but off if targeting any /specific/ non-GDB debugger.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 <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></blockquote><div><br>In the source, probably - somewhere near the enum or major entry point to querying it.<br><br>We might want to talk a bit more about when to err on the side of caution & put something in for every debugger by default, an opt out of it when tuning for a debugger that doesn't need it.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
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>
</blockquote></div><br></div></div>