<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:LucidaGrande;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Comments on the patch raise the following questions, probably better discussed here.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">First: Should LLVM default to "no tuning" rather than a target-specific default?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">There are two natural follow-up questions: What would "no tuning" actually mean? Where would the target-specific defaulting occur?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I originally came down against the "no tuning" option, in favor of the historical GDB default, because in fact it wasn't really clear what "no tuning" should
mean. The best answer I can come up with is: Emit all standard things that we know how to emit, and no non-standard things. This would mean: pubnames/pubtypes, aranges, no accelerator tables, standard TLS opcode. Possibly type units, although that's currently
not a tuning thing, and support for it isn't particularly widespread.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If LLVM doesn't do target-specific defaulting, then Clang would have to.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Second: The GNU TLS opcode thing is really a GDB bug, not a "tuning" consideration.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">That's true…. but we have no other better mechanism for dealing with it. I'm open to suggestions but as this is the only clearly bug-like case, I think I'd
be willing to live with it. Making the decision based on target, which is what we do today, feels stupider.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
<b>On Behalf Of </b>Robinson, Paul<br>
<b>Sent:</b> Wednesday, May 06, 2015 2:40 PM<br>
<b>To:</b> Adrian Prantl; Eric Christopher<br>
<b>Cc:</b> lldb-dev@cs.uiuc.edu; cfe-dev@cs.uiuc.edu Developers (cfe-dev@cs.uiuc.edu); LLVM Developers Mailing List (llvmdev@cs.uiuc.edu)<br>
<b>Subject:</b> Re: [LLVMdev] [lldb-dev] [cfe-dev] What does "debugger tuning" mean?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">@Adrian, "I don't think there was a driver patch" actually yes there is, see below.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">@Eric, "Does the patch do all of this?" Basically, yes, see
</span><a href="http://reviews.llvm.org/D8506"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">http://reviews.llvm.org/D8506</span></a><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The target-based default for the tuning parameter is done by code at the top of the DwarfDebug constructor; this really simplified supporting an option from
the tool command lines (CommandFlags.h) and passing in a value from Clang. Given that the use of LLDB seems to be more aligned with OS than target architecture, trying to set up appropriate default tuning values somewhere under lib/Target just seemed too
complicated. But if that's what you'd rather see, please comment in the patch.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Unpacking the tuning parameter into defaults for other feature flags happens in the rest of the DwarfDebug constructor; I didn't immediately change all current
target-based defaulting into tuning-based defaulting, although I could if you want. Please comment in the patch if that's the case.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Existing cl::opt stuff for existing feature flags is all still there; the tuning parameter affects only the defaults, so you can ask for particular tuning and
still override what it does for some specific feature.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">DwarfDebug stuff outside the constructor is unaffected, it's all using the existing feature flags.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Future work includes:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Replace various Darwin checks with tuning checks. I see one Darwin check that is _not_ inside the DwarfDebug ctor, that probably should be replaced with a proper
feature flag that gets defaulted appropriately in the ctor. (Which also lets us remove the IsDarwin field from the class.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Add feature flags for the various other things mentioned on the thread (linkage names, figuring out what to do with DW_AT_APPLE_* attributes, etc) with appropriate
defaulting.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Oh yeah, the Clang command-line option, which has its own review (</span><a href="http://reviews.llvm.org/D8599"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">http://reviews.llvm.org/D8599</span></a><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">)
but needs a whole 'nother round of discussion and bikeshedding that didn't seem relevant to the LLVM part. I haven't been pinging it because we needed to get the LLVM part sorted first.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Eventually there would be Clang things probably that want to be tuning-influenced, e.g. the inherit-from-forward-decl thing that Greg mentioned seems very likely
to be a Clang thing.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Anything else to talk about?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Adrian Prantl [<a href="mailto:aprantl@apple.com">mailto:aprantl@apple.com</a>]
<br>
<b>Sent:</b> Wednesday, May 06, 2015 1:21 PM<br>
<b>To:</b> Eric Christopher<br>
<b>Cc:</b> Robinson, Paul; David Blaikie; <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a>;
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a> Developers (<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>); LLVM Developers Mailing List (<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>)<br>
<b>Subject:</b> Re: [lldb-dev] [LLVMdev] [cfe-dev] What does "debugger tuning" mean?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I don’t think there was a driver patch so far, was there?<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-- adrian<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On May 6, 2015, at 1:19 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Does the patch do all of this?<br>
<br>
-eric<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, May 6, 2015 at 1:18 PM Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com">Paul_Robinson@playstation.sony.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I just skimmed through the thread again, and I *think* all the main questions have been answered…</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">It feels like the consensus is "reluctant agreement," with the specific design points being:</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">a "debugger tuning" option would have some sort of target-based default</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">the "debugger tuning" option would unpack into defaults for individual feature flags</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">emitting actual DWARF would test the feature flags not the tuning option</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-</span><span style="font-size:7.0pt;color:#1F497D">
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">any command-line options for feature flags would override the tuning-based defaults</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If I missed anything, let me know, otherwise I'll go back go pinging the patch.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a name="msg-f:1500453035452317154__MailEndCompos"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></a><o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.uiuc.edu</a>]
<b>On Behalf Of </b>David Blaikie<br>
<b>Sent:</b> Tuesday, May 05, 2015 8:21 PM<br>
<b>To:</b> Adrian Prantl<br>
<b>Cc:</b> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a>; Greg Clayton;
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a> Developers (<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a>); LLVM Developers Mailing List (<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>)<br>
<b>Subject:</b> Re: [LLVMdev] [cfe-dev] [lldb-dev] What does "debugger tuning" mean?</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Tue, May 5, 2015 at 8:16 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On May 5, 2015, at 8:12 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:9.0pt;font-family:"LucidaGrande","serif"">On Tue, May 5, 2015 at 4:04 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:9.0pt;font-family:"LucidaGrande","serif""><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>
I think the option is -f(no-)standalone-debug-info</span><o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:9.0pt;font-family:"LucidaGrande","serif""><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)</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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>
<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:9.0pt;font-family:"LucidaGrande","serif""> </span><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:9.0pt;font-family:"LucidaGrande","serif"">which only emits full definitions of classes in the object file that holds and object’s vtable.<br>
<span style="color:#888888"><br>
-- adrian</span></span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span style="font-size:9.0pt;font-family:"LucidaGrande","serif"">><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 <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>
>>>> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
>>>> <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>
> <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>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:9.0pt;font-family:"LucidaGrande","serif"">_______________________________________________<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></span><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>