[LLVMdev] What does "debugger tuning" mean?

[Robinson, Paul]

> -----Original Message-----
> From: Daniel Berlin [mailto:dberlin at dberlin.org]
> Sent: Friday, May 01, 2015 3:15 PM
> To: Robinson, Paul
> Cc: cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM Developers
> Mailing List (llvmdev at cs.uiuc.edu); lldb-dev at cs.uiuc.edu
> Subject: Re: [LLVMdev] What does "debugger tuning" mean?
> 
> On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul
> <Paul_Robinson at playstation.sony.com> wrote:
> 
> >
> > LLVM already emits DWARF slightly differently for different *targets*;
> > primarily Darwin, in a few cases PS4.  But in at least some cases, the
> > target is just a (somewhat unreliable) proxy for which *debugger* the
> > compiler expects to be consuming the DWARF.  The most instructive case
> > is the exact DWARF expression used to describe the location of a thread-
> > local variable.  DWARF v3 defined an operator to find the base address
> > of the thread-local storage area; however, GDB has never learned to
> > recognize it.  Therefore, for targets where we "know" GDB isn't used,
> > we can emit the standard operator; for targets where GDB *might* be
> > used, we need to emit the equivalent (non-standard) GNU operator.
> >
> > It would be semantically more meaningful to base decisions like this on
> > whether we expected the debugger to be X or Y or Z.
> 
> How is this not actually "we expect the debugger to want his described
> as X, Y, and Z" instead of "we expect the debugger to by X or Y or Z".

Different ways of describing things let us reason about them in different
ways.  Are Cartesian coordinates a reason to reject polar coordinates?

> Debuggers change over time.

Well, they're software too.  They're allowed.

> GDB 4's level of support != GDB 5 != GDB6 != GDB7.
> 
> Heck, the same version of GDB on different platforms can be very
> different (HP's GDB was very different, as was Apple's).
> 
> Do you plan on having "debugger tuning" flags for each of these?

Are all of these current supported Clang/LLVM environments?  Are they
suffering because Clang currently emits DWARF in ways that cause them
problems, or that bloats the debug info unnecessarily?  Are vendors
carrying a pile of private patches to get LLVM to emit DWARF that looks
like what their debugger wants?  If the answer to these questions is
Yes then my answer to your question is Sure, we could, if we find 
those differences to be important.

I promise you that these things are true at Sony, and I would be
astounded if it wasn't true for Apple. Guess what? LLDB and SCE are
two of the debugger-tuning options for a reason.

Show me another _real_ case of _real_ differences that matter to the
community, and we can talk about another debugger tuning option.

> I am having a lot of trouble understanding how this is about what
> debuggers expect and not "ways of representing things".

Sometimes there's not much difference in the result, although there
is a difference in how we think about it.

> Otherwise, i see you getting stuck introducing tons and tons of
> debugger tunings, instead of people who want it to work a certain way
> building an option profile consisting of
> "--debugging-feature=use-tls-operator
> --debugging-feature=explicit-anonymous-namespace", and getting exactly
> what they want.

(That sort of alternate proposal is way more useful than the straw-man
stuff you started out with.  Just sayin'.)

(Also incidentally, I see gcc 4.8.2 is emitting an explicit import of
anonymous namespaces, so that's becoming _less_ different over time.)

In fact this is more or less how DwarfDebug operates now; there is a
pile (small pile, but still a pile) of individual feature flags that
get set various ways depending on target or command-line options.
The problem I'm looking at is that the defaults for a lot of these 
things are based on target, which AFAICT is based on an out-of-date
assumption about how target correlates to debugger.

I'm proposing to package up known sets of stuff that we're having to
contend with _today_ in a way that's easier to talk about and do
something about than the target-oriented mish-mash we have now.

It's a whole lot simpler to say something like "FreeBSD implies LLDB"
instead of "FreeBSD implies accelerator tables and standard TLS opcode
and no pubnames or pubtypes."

Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref
--lang-feature=move_ctor ..." than "-std=c++11"?


> IE a year from now, somebody comes along with a version of GDB that
> doesn't match what your current "tuning profile" is, and asks for it
> to change.

If it's meaningfully different, i.e. makes enough of a functional and/or
size difference, and it's an environment we collectively want to support,
and it's unreasonable to get the necessary effect some other way, then
sure, maybe we would want to invent a new tuning profile.

But, if it doesn't meet that bar, I don't see why we'd want to.
--paulr