<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;}
/* 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;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@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" style="margin-left:.5in">FWIW I'd be surprised if Apple's carrying much internal cost for LLVM's debug info.<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hmm maybe. Adrian seemed awfully excited about the TLS opcode patch, though.<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""> David Blaikie [mailto:dblaikie@gmail.com]
<br>
<b>Sent:</b> Friday, May 01, 2015 5:11 PM<br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> Daniel Berlin; 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: [cfe-dev] [LLVMdev] What does "debugger tuning" mean?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, May 1, 2015 at 4:57 PM, Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">> -----Original Message-----<br>
> From: Daniel Berlin [mailto:<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>]<br>
> Sent: Friday, May 01, 2015 3:15 PM<br>
> To: Robinson, Paul<br>
> Cc: <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<br>
> Mailing List (<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>); <a href="mailto:lldb-dev@cs.uiuc.edu">
lldb-dev@cs.uiuc.edu</a><br>
> Subject: Re: [LLVMdev] What does "debugger tuning" mean?<br>
><br>
> On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul<br>
> <<a href="mailto:Paul_Robinson@playstation.sony.com">Paul_Robinson@playstation.sony.com</a>> wrote:<br>
><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.<br>
><br>
> How is this not actually "we expect the debugger to want his described<br>
> as X, Y, and Z" instead of "we expect the debugger to by X or Y or Z".<br>
<br>
Different ways of describing things let us reason about them in different<br>
ways. Are Cartesian coordinates a reason to reject polar coordinates?<br>
<br>
> Debuggers change over time.<br>
<br>
Well, they're software too. They're allowed.<br>
<br>
> GDB 4's level of support != GDB 5 != GDB6 != GDB7.<br>
><br>
> Heck, the same version of GDB on different platforms can be very<br>
> different (HP's GDB was very different, as was Apple's).<br>
><br>
> Do you plan on having "debugger tuning" flags for each of these?<br>
<br>
Are all of these current supported Clang/LLVM environments? Are they<br>
suffering because Clang currently emits DWARF in ways that cause them<br>
problems, or that bloats the debug info unnecessarily? Are vendors<br>
carrying a pile of private patches to get LLVM to emit DWARF that looks<br>
like what their debugger wants? If the answer to these questions is<br>
Yes then my answer to your question is Sure, we could, if we find<br>
those differences to be important.<br>
<br>
I promise you that these things are true at Sony, and I would be<br>
astounded if it wasn't true for Apple.<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
FWIW I'd be surprised if Apple's carrying much internal cost for LLVM's debug info. It was essentially built for ye olde GDB and even when I set about improving it I brought up an external buildbot for that workload to ensure it wasn't broken (& LLDB was built
for LLVM's debug info output, so there's not much reason to expect that wouldn't work - the base class declaration's one of the only cases there that I know of - and yes, that's predicated on Darwin & should be predicated on LLDB as you're proposing)<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-right:0in">
<p class="MsoNormal">Guess what? LLDB and SCE are<br>
two of the debugger-tuning options for a reason.<br>
<br>
Show me another _real_ case of _real_ differences that matter to the<br>
community, and we can talk about another debugger tuning option.<br>
<br>
> I am having a lot of trouble understanding how this is about what<br>
> debuggers expect and not "ways of representing things".<br>
<br>
Sometimes there's not much difference in the result, although there<br>
is a difference in how we think about it.<br>
<br>
> Otherwise, i see you getting stuck introducing tons and tons of<br>
> debugger tunings, instead of people who want it to work a certain way<br>
> building an option profile consisting of<br>
> "--debugging-feature=use-tls-operator<br>
> --debugging-feature=explicit-anonymous-namespace", and getting exactly<br>
> what they want.<br>
<br>
(That sort of alternate proposal is way more useful than the straw-man<br>
stuff you started out with. Just sayin'.)<br>
<br>
(Also incidentally, I see gcc 4.8.2 is emitting an explicit import of<br>
anonymous namespaces, so that's becoming _less_ different over time.)<br>
<br>
In fact this is more or less how DwarfDebug operates now; there is a<br>
pile (small pile, but still a pile) of individual feature flags that<br>
get set various ways depending on target or command-line options.<br>
The problem I'm looking at is that the defaults for a lot of these<br>
things are based on target, which AFAICT is based on an out-of-date<br>
assumption about how target correlates to debugger.<br>
<br>
I'm proposing to package up known sets of stuff that we're having to<br>
contend with _today_ in a way that's easier to talk about and do<br>
something about than the target-oriented mish-mash we have now.<br>
<br>
It's a whole lot simpler to say something like "FreeBSD implies LLDB"<br>
instead of "FreeBSD implies accelerator tables and standard TLS opcode<br>
and no pubnames or pubtypes."<br>
<br>
Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref<br>
--lang-feature=move_ctor ..." than "-std=c++11"?<br>
<br>
<br>
> IE a year from now, somebody comes along with a version of GDB that<br>
> doesn't match what your current "tuning profile" is, and asks for it<br>
> to change.<br>
<br>
If it's meaningfully different, i.e. makes enough of a functional and/or<br>
size difference, and it's an environment we collectively want to support,<br>
and it's unreasonable to get the necessary effect some other way, then<br>
sure, maybe we would want to invent a new tuning profile.<br>
<br>
But, if it doesn't meet that bar, I don't see why we'd want to.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">--paulr<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">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><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>