<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 1, 2015 at 4:57 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"><span class="">> -----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>
</span><span class="">> 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>
</span>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>
<span class=""><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>
</span>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.</blockquote><div><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> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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>
<span class=""><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>
</span>Sometimes there's not much difference in the result, although there<br>
is a difference in how we think about it.<br>
<span class=""><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>
</span>(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>
<span class=""><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>
</span>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.<br>
<div class="HOEnZb"><div class="h5">--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><br>
</div></div></blockquote></div><br></div></div>