llvm dev - May 2015 - [LLVMdev] [lldb-dev] [cfe-dev] What does "debugger tuning" mean?

In some cases we do want to make the decision based on the target. For Hexagon,
we don't support GDB anymore, only LLDB, so we always want LLDB tuning. The
clang driver should have a way to specify that.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Adrian Prantl
Sent: Friday, May 08, 2015 10:11 AM
To: Robinson, Paul
Cc: lldb-dev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu Developers (cfe-dev at
cs.uiuc.edu); LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
Subject: Re: [LLVMdev] [lldb-dev] [cfe-dev] What does "debugger
tuning" mean?

> On May 8, 2015, at 7:24 AM, Robinson, Paul <Paul_Robinson at
playstation.sony.com> wrote:
> 
> Comments on the patch raise the following questions, probably better
discussed here.
>  
> First: Should LLVM default to "no tuning" rather than a
target-specific default?
> There are two natural follow-up questions:  What would "no
tuning" actually mean?  Where would the target-specific defaulting occur?
> 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.
> If LLVM doesn't do target-specific defaulting, then Clang would have
to.
Since you are calling out “no accelerator tables”, this made me think about how
the .apple-* accelerator tables (and most of the DW_AT_APPLE* attributes) fit
into this. I sounds like they should be target-specific on Darwin while also
being enabled by the LLDB tuning option: On Darwin, both LLDB and the Apple
version of GDB support them, while on Linux they are only supported by LLDB.
> Second: The GNU TLS opcode thing is really a GDB bug, not a
"tuning" consideration.
> 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.
Agreed.
-- adrian
> --paulr
>  
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Robinson, Paul
> Sent: Wednesday, May 06, 2015 2:40 PM
> To: Adrian Prantl; Eric Christopher
> Cc: lldb-dev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu Developers 
> (cfe-dev at cs.uiuc.edu); LLVM Developers Mailing List 
> (llvmdev at cs.uiuc.edu)
> Subject: Re: [LLVMdev] [lldb-dev] [cfe-dev] What does "debugger
tuning" mean?
>  
> @Adrian, "I don't think there was a driver patch" actually
yes there is, see below.
> @Eric, "Does the patch do all of this?"  Basically, yes, see 
> http://reviews.llvm.org/D8506 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.
> 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.
> 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.
> DwarfDebug stuff outside the constructor is unaffected, it's all using
the existing feature flags.
>  
> Future work includes:
> 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.) 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.
> Oh yeah, the Clang command-line option, which has its own review
(http://reviews.llvm.org/D8599) 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.
> 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.
>  
> Anything else to talk about?
> --paulr
>  
> From: Adrian Prantl [mailto:aprantl at apple.com]
> Sent: Wednesday, May 06, 2015 1:21 PM
> To: Eric Christopher
> Cc: Robinson, Paul; David Blaikie; lldb-dev at cs.uiuc.edu; 
> cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM Developers
> Mailing List (llvmdev at cs.uiuc.edu)
> Subject: Re: [lldb-dev] [LLVMdev] [cfe-dev] What does "debugger
tuning" mean?
>  
> I don’t think there was a driver patch so far, was there?
>  
> -- adrian
>  
> On May 6, 2015, at 1:19 PM, Eric Christopher <echristo at gmail.com>
wrote:
>  
> Does the patch do all of this?
> 
> -eric
>  
> On Wed, May 6, 2015 at 1:18 PM Robinson, Paul <Paul_Robinson at
playstation.sony.com> wrote:
> I just skimmed through the thread again, and I *think* all the main 
> questions have been answered… It feels like the consensus is
"reluctant agreement," with the specific design points being:
> -        a "debugger tuning" option would have some sort of
target-based default
> -        the "debugger tuning" option would unpack into defaults
for individual feature flags
> -        emitting actual DWARF would test the feature flags not the tuning
option
> -        any command-line options for feature flags would override the
tuning-based defaults
>  
> If I missed anything, let me know, otherwise I'll go back go pinging
the patch.
> Thanks,
> --paulr
>  
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of David Blaikie
> Sent: Tuesday, May 05, 2015 8:21 PM
> To: Adrian Prantl
> Cc: lldb-dev at cs.uiuc.edu; Greg Clayton; cfe-dev at cs.uiuc.edu
Developers
> (cfe-dev at cs.uiuc.edu); LLVM Developers Mailing List 
> (llvmdev at cs.uiuc.edu)
> Subject: Re: [LLVMdev] [cfe-dev] [lldb-dev] What does "debugger
tuning" mean?
>  
>  
>  
> On Tue, May 5, 2015 at 8:16 PM, Adrian Prantl <aprantl at apple.com>
wrote:
>  
> On May 5, 2015, at 8:12 PM, David Blaikie <dblaikie at gmail.com>
wrote:
>  
>  
> 
> On Tue, May 5, 2015 at 4:04 PM, Adrian Prantl <aprantl at apple.com>
wrote:
> 
> > On May 1, 2015, at 2:18 PM, Greg Clayton <gclayton at apple.com>
wrote:
> >
> >
> >> On May 1, 2015, at 2:00 PM, Robinson, Paul <Paul_Robinson at
playstation.sony.com> wrote:
> >>
> >>> A few more things that vote for debugger tuning:
> >>>
> >>> - LLDB doesn't like to have DWARF that has a class A that
inherits
> >>> from class B, but only a forward declaration of class B is
provided.
> >>
> >> Hmm do we emit that kind of thing today?  In a naïve test, I'm
> >> seeing the full description of class B.
> >
> > by default for darwin, it doesn't do this. For others you must
specify -fno-limit-debug-info or some flag like that.
> 
> I think the option is -f(no-)standalone-debug-info
> 
> -fno-limit-debug-info == -fstandalone-debug (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)
>  
> 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.
> 
> 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:
> 
> 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))
> 2) vtable (if a type is dynamic, only emit its definition where the 
> vtable is emitted)
> 3) explicit template instantiation (if a type has an explicit template 
> instantiation declaration, only emit the definition where the explicit 
> template instantiation definition is)
> 
> 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)
>  
>  
> 
>  
> which only emits full definitions of classes in the object file that holds
and object’s vtable.
> 
> -- adrian
> >
> >>> - LLDB wants the .apple_XXX accelerator tables, GDB wants 
> >>> .debug_pubnames/.debug_pubtypes
> >>
> >> Agreed.
> >>
> >>> So it would be great to have a "-debugger" flag that
could be
> >>> specified
> >>>
> >>> -debugger=lldb
> >>> -debugger=gdb
> >>>
> >>> Not sure on the option name, but I do like the idea.
> >>
> >> We'll bikeshed the name later but yes, that's the plan.
> >> Thanks,
> >> --paulr
> >>
> >>>
> >>> Greg
> >>>
> >>>> On May 1, 2015, at 1:06 PM, Robinson, Paul
> >>> <Paul_Robinson at playstation.sony.com> wrote:
> >>>>
> >>>> This is basically a reboot of the previous thread titled
About
> >>>> the "debugger target"
> >>>> except that "target" was really too strong a
term for what I had
> >>> intended
> >>>> to use this feature for.  "Debugger tuning" is
more like it.  You
> >>>> don't need to have read the previous thread, I'll
recap here.
> >>>>
> >>>> Fundamentally, Clang/LLVM uses DWARF as the specification
for the
> >>> _format_
> >>>> of information provided by the compiler to a variety of
"consumers,"
> >>> which
> >>>> primarily means debuggers (but not exclusively).  [For a
long
> >>>> time it
> >>> was
> >>>> the only format supported by LLVM. Lately, Microsoft debug
info
> >>>> has
> >>> started
> >>>> appearing, but being a less widely used format, the issues
that
> >>>> DWARF
> >>> runs
> >>>> into aren't a concern for that format.  So
"debugger tuning" is
> >>>> unlikely to be an issue for Microsoft debug info.]
> >>>>
> >>>> DWARF is a permissive standard, meaning that it does not
rigidly
> >>>> require that source-language construct X must be described
using
> >>>> the DWARF construct Y.  Instead, DWARF says something more
like,
> >>>> "If you have a source construct that means something
like X,
> >>>> here's a mechanism Y that you could use to describe
it."  While
> >>>> this gives compilers a lot of nice flexibility, it does
mean that
> >>>> there's a lot of wiggle room for how a compiler
describes
> >>>> something and in how a debugger interprets that
description.
> >>>> Compilers and debuggers therefore need to do a bit of
negotiation
> >>>> in determining how the debug-info "contract"
will work, when it
> >>>> comes to nitty-gritty details.  DWARF itself (the
standard, as
> >>>> well as the committee that owns the standard) refuses to
get
> >>>> involved in this negotiation, referring to all that as
"quality
> >>>> of implementation
> >>> issues."
> >>>>
> >>>> It is readily apparent that different debuggers have
different
> >>>> ideas about certain DWARF features, for example whether
they are
> >>>> useful or irrelevant, or whether a certain source
construct
> >>>> should be described this way or that way.  As these
generally
> >>>> fall into the QOI realm, the DWARF spec itself is no help,
and it
> >>>> comes down to a matter of opinion about whether "the
debugger
> >>>> should just know this" or "the compiler really
ought to just emit it that way."
> >>>>
> >>>> Clang/LLVM is in the position of being a compiler that
wants to
> >>>> support several different debuggers, all of which have
slightly
> >>>> different ideas about what they want from the DWARF info
for a
> >>>> program.  Our first line of defense of course is the DWARF
> >>>> standard itself, but as we've seen, that is not a
universally definitive reference.
> >>>>
> >>>> 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.
> >>>> Therefore I've proposed
(http://reviews.llvm.org/D8506) a
> >>>> "debugger tuning" option that will make the
reasoning behind
> >>>> these choices more obvious, and
> >>> ultimately
> >>>> give users a way to control the tuning themselves, when
the
> >>>> platform's default isn't what they want. (I'll
have a follow-up
> >>>> patch exposing the tuning option to the Clang driver.)
> >>>>
> >>>> So, what kinds of things should be based on the debugger
tuning option?
> >>>> Are there still things that should be based on the target
platform?
> >>>> Simplest to consider these questions together, because it
is
> >>>> often clear which criterion is important if you consider
(a) the
> >>>> same debugger run on different targets, versus (b)
different
> >>>> debuggers running on the same target.  Basically, if the
same
> >>>> debugger on different targets wants to have something a
certain way, that's probably a debugger-tuning thing.
> >>>> And if different debuggers on the same target doesn't
mean you
> >>>> should change how the DWARF looks, that's likely a
platform-specific thing.
> >>>>
> >>>> The most obvious example of a debugger-tuning
consideration is
> >>>> the TLS operator mentioned above. That's something
that GDB insists on having.
> >>>> (It turns out that the standard operator was defined in
DWARF 3,
> >>>> so we also have to emit the GNU operator if we're
producing DWARF
> >>>> 2.  Tuning considerations don't trump what the
standard says.)
> >>>>
> >>>> Another example would be .debug_pubnames and
.debug_pubtypes sections.
> >>>> Currently these default to omitted for Darwin and PS4, but
> >>>> included everywhere else. My initial patch for
"tuning" changes
> >>>> the PS4 platform criterion to the SCE debugger predicate;
quite likely the "not Darwin"
> >>>> criterion ought to be "not LLDB" or in other
words "on for GDB only."
> >>>> And having the code actually reflect the correct semantic
purpose
> >>>> seems like an overall goodness.
> >>>>
> >>>> An example of a target-dependent feature might be the 
> >>>> .debug_aranges section. As it happens, we don't emit
this section
> >>>> by default, because apparently no debugger finds it
useful,
> >>>> although there's a command-line option
(-gdwarf-aranges) for it.
> >>>> But, for PS4 we do want to emit it, because we have
non-debugger
> >>>> tools that find it useful.  We haven't yet done the
work to make that change on llvm.org, but it's on the list.
> >>>> I would conditionalize this on the target, not the
debugger,
> >>>> because the debugger is not why we want to generate the
section.
> >>>>
> >>>> Okay, so I've been pretty long-winded about all this,
can I
> >>>> possibly codify it all into a reasonably succinct set of 
> >>>> guidelines?  (which ought to be committed to the repo
somewhere,
> >>>> although whether it's as a lump of text in a docs
webpage or a
> >>>> lump of commentary in some source file is not clear;
opinions
> >>>> welcome.)
> >>>>
> >>>> o Emit standard DWARF if possible.
> >>>> o Omitting standard DWARF features that nobody uses is
fine.
> >>>> (example: DW_AT_sibling)
> >>>> o Extensions are okay, but think about the circumstances
where
> >>>> they would be useful (versus just wasting space).  These
are
> >>>> probably a debugger tuning decision, but might be a
target-based decision.
> >>>> (example: DW_AT_APPLE_* attributes) o If some debugger
can't
> >>>> tolerate some piece of standard DWARF, that's a
missing feature
> >>>> or a bug in the debugger.  Accommodating that in the
compiler is
> >>>> a debugger tuning decision.
> >>>> (example: DW_OP_form_tls_address not understood by GDB) o
If some
> >>>> debugger has no use for some piece of standard DWARF, and
it
> >>>> saves space to omit it, that's a debugger tuning
decision.
> >>>> (example: .debug_pubnames/.debug_pubtypes sections) o If a
> >>>> debugger wants things a certain way regardless of the
target,
> >>>> that's probably a debugger tuning decision.
> >>>> o If "system" software on a target (other than
the debugger)
> >>>> wants things a certain way regardless of which debugger
you're
> >>>> using, that's NOT a debugger tuning decision, but a
target-based decision.
> >>>> (example: .debug_aranges section)
> >>>>
> >>>> Let me know if this all seems reasonable, and especially
if you
> >>>> have a good idea where to keep the guidelines.
> >>>> Thanks,
> >>>> --paulr
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> lldb-dev mailing list
> >>>> lldb-dev at cs.uiuc.edu
> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >>
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>  
>  
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

> -----Original Message-----
> From: Ted Woodward [mailto:ted.woodward at codeaurora.org]
> Sent: Friday, May 08, 2015 9:01 AM
> To: 'Adrian Prantl'; Robinson, Paul
> Cc: lldb-dev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu
> Subject: RE: [LLVMdev] [lldb-dev] [cfe-dev] What does "debugger
tuning"
> mean?
> 
> In some cases we do want to make the decision based on the target. For
> Hexagon, we don't support GDB anymore, only LLDB, so we always want
LLDB
> tuning. The clang driver should have a way to specify that.
There will definitely be target-based defaulting, although exactly where
it will happen is still a little bit up in the air.
--paulr
> 
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project

After far too long being distracted by other things, I'm getting back to
this.

To recap, today we have a handful of feature flags in the DwarfDebug
class which control various bits of DWARF; these feature flags can mostly
be set by command-line flags or front-ends, but otherwise tend to have
target-based defaults.

The proposal is to introduce a "debugger tuning" option, which will
allow
us to fine-tune DWARF output based on what various debuggers prefer to 
see, or conversely leave out things they don't care about.  This replaces 
the current tactic of assuming debugger features are tied to the target, 
which is at best incomplete and at worst wrong.  By making the expected 
debugger explicit, we separate the concerns about target versus debugger, 
and clarify the intent of decisions made based on one or the other factor.

The main debuggers of interest to the LLVM community are:
- GDB, the old warhorse
- LLDB, the new kid on the block
- SCE, for lack of a better name for Sony's debugger
  (SCE = Sony Computer Entertainment; this debugger supports various
  game consoles so we're unwilling to call it the PS4 debugger, and
  it doesn't really have a name per se.)

Given a particular "debugger tuning" we can set the feature flags
based
more obviously and clearly on the toolchain component that most cares
about the features, i.e. the debugger.  Code to actually emit DWARF in
one way or another would still rely on the feature flags.

While there is a patch up for review (http://reviews.llvm.org/D8506)
some of the questions raised there might be better discussed on the list,
which is what I'm doing now.

Q1. Will the debugger tuning override individual feature flags?

A1. No. Tuning for a debugger will "unpack" into defaults for the
various
feature flags, but individual command-line options for those feature flags
will still have the last word.

Q2. You based the DWARF TLS opcode choice on debugger tuning, but that is
a GDB bug rather than a real "tuning" thing.

A2. True. Basing it on tuning seems to me less bad than leaving it based
on target, which is what we have now.  I'm okay with reverting that bit; 
I don't want "tuning" to get misconstrued as "it's just a
way to work
around debugger bugs" because it's not.

Q3. If I want my target to have a particular debugger tuning by default,
how do I make that happen?

A3. To date, this has been done with explicit triple-based tests in the
DwarfDebug class constructor. If there's a smoother way to make this a 
target-based parameter, which DwarfDebug can query, that works for me.

The debugger-to-use seems more closely tied to OS than to the target 
architecture, and LLVM's existing Target-based stuff is primarily aligned
with architecture, making it a less natural fit.  Suggestions welcome, as
I find it hard to keep straight all the various ways that target-specific 
things get specified.

Q4. Should LLVM default to "no special tuning" rather than a
particular
debugger?

A4. That does feel like an attractive idea, however it would be a
noticeable change in responsibility from what we have today (which is
basically GDB everywhere except Darwin and PS4, as a decision made by
LLVM).  If LLVM doesn't set a default, then it would be up to each 
front-end to explicitly set the default, and that is not a responsibility 
they're really expecting to have.

I did experiment with "no special tuning" as the default, and once I
realized that meant "emit optional but standardized stuff" i.e. the
pubnames/pubtypes sections, only one test failed, which had been expecting
the triple to determine whether those sections appeared.

Of course that's only the tests, it says nothing about the actual user 
experience.  It's not like I tried running the GDB suite in a "no
special
tuning" mode.

The whole "how should the tuning default work?" question seems like it
needs a broader discussion. There really seem to be three options.

- In the DwarfDebug constructor.  This is where it is (in effect) now, as
a series of triple-based checks.  My initial patch left it there, more 
explicitly, but still as a series of triple-based checks; basically the 
patch made it possible to override, but the defaulting worked the same way 
as before.

- In some Target class.  The problem with this (as noted above) is that 
Target is well-aligned with architecture, and poorly aligned with OS, 
while the choice of default debugger is basically an OS kind of thing.  
I confess when it comes to Target stuff, I quickly get lost in the twisty 
maze of little passages all different, so any suggestions here of (a) a 
way to make this OS-based decision (b) in a way that DwarfDebug can query,
would be very welcome.

- In each front-end/tool (not LLVM).  Again as noted above, this is not a 
decision that front-ends/tools are making today, and adding this to their 
list of responsibilities might be inappropriate.

Opinions about the appropriate way to do the defaulting?

Thanks,
--paulr

> On Jun 4, 2015, at 4:35 PM, Robinson, Paul <Paul_Robinson at
playstation.sony.com> wrote:
> 
> After far too long being distracted by other things, I'm getting back
to
> this.
> 
> To recap, today we have a handful of feature flags in the DwarfDebug
> class which control various bits of DWARF; these feature flags can mostly
> be set by command-line flags or front-ends, but otherwise tend to have
> target-based defaults.
> 
> The proposal is to introduce a "debugger tuning" option, which
will allow
> us to fine-tune DWARF output based on what various debuggers prefer to 
> see, or conversely leave out things they don't care about.  This
replaces
> the current tactic of assuming debugger features are tied to the target, 
> which is at best incomplete and at worst wrong.  By making the expected 
> debugger explicit, we separate the concerns about target versus debugger, 
> and clarify the intent of decisions made based on one or the other factor.
> 
> The main debuggers of interest to the LLVM community are:
> - GDB, the old warhorse
> - LLDB, the new kid on the block
> - SCE, for lack of a better name for Sony's debugger
>  (SCE = Sony Computer Entertainment; this debugger supports various
>  game consoles so we're unwilling to call it the PS4 debugger, and
>  it doesn't really have a name per se.)
> 
> Given a particular "debugger tuning" we can set the feature flags
based
> more obviously and clearly on the toolchain component that most cares
> about the features, i.e. the debugger.  Code to actually emit DWARF in
> one way or another would still rely on the feature flags.
> 
> While there is a patch up for review (http://reviews.llvm.org/D8506)
> some of the questions raised there might be better discussed on the list,
> which is what I'm doing now.
> 
> Q1. Will the debugger tuning override individual feature flags?
> 
> A1. No. Tuning for a debugger will "unpack" into defaults for the
various
> feature flags, but individual command-line options for those feature flags
> will still have the last word.
> 
> Q2. You based the DWARF TLS opcode choice on debugger tuning, but that is
> a GDB bug rather than a real "tuning" thing.
> 
> A2. True. Basing it on tuning seems to me less bad than leaving it based
> on target, which is what we have now.  I'm okay with reverting that
bit;
> I don't want "tuning" to get misconstrued as "it's
just a way to work
> around debugger bugs" because it's not.
I agree that having a workaround for a bug in a specific debugger tied to a
target is clearly wrong for all the reasons cited in the second paragraph. We
shouldn’t be doing that.

Personally I don’t have a problem with making workarounds a (small) part of the
debugger tuning, because they really are something that is tied to a specific
debugger.

As a user I expect `clang -g` with no further options to produce a binary for my
current system with debug info that can be understood by the system debugger.
One way to achieve this is that a target implies a debugger tuning setting,
which then enables the workarounds for that debugger.

Workarounds may be more short-lived than other debugger tuning options, however:
How do we handle a workaround for a bug in GDB 7 that is fixed in GDB 8?
> 
> Q3. If I want my target to have a particular debugger tuning by default,
> how do I make that happen?
> 
> A3. To date, this has been done with explicit triple-based tests in the
> DwarfDebug class constructor. If there's a smoother way to make this a 
> target-based parameter, which DwarfDebug can query, that works for me.
> 
> The debugger-to-use seems more closely tied to OS than to the target 
> architecture, and LLVM's existing Target-based stuff is primarily
aligned
> with architecture, making it a less natural fit.  Suggestions welcome, as
> I find it hard to keep straight all the various ways that target-specific 
> things get specified.
> 
> Q4. Should LLVM default to "no special tuning" rather than a
particular
> debugger?
> 
> A4. That does feel like an attractive idea, however it would be a
> noticeable change in responsibility from what we have today (which is
> basically GDB everywhere except Darwin and PS4, as a decision made by
I think that FreeBSD is also using (or at least moving towards) LLDB as the
system debugger.
> LLVM).  If LLVM doesn't set a default, then it would be up to each 
> front-end to explicitly set the default, and that is not a responsibility 
> they're really expecting to have.
> 
> I did experiment with "no special tuning" as the default, and
once I
> realized that meant "emit optional but standardized stuff" i.e.
the
> pubnames/pubtypes sections, only one test failed, which had been expecting
> the triple to determine whether those sections appeared.
> 
> Of course that's only the tests, it says nothing about the actual user 
> experience.  It's not like I tried running the GDB suite in a "no
special
> tuning" mode.
> 
> The whole "how should the tuning default work?" question seems
like it
> needs a broader discussion. There really seem to be three options.
> 
> - In the DwarfDebug constructor.  This is where it is (in effect) now, as
> a series of triple-based checks.  My initial patch left it there, more 
> explicitly, but still as a series of triple-based checks; basically the 
> patch made it possible to override, but the defaulting worked the same way 
> as before.
> 
> - In some Target class.  The problem with this (as noted above) is that 
> Target is well-aligned with architecture, and poorly aligned with OS, 
> while the choice of default debugger is basically an OS kind of thing.  
> I confess when it comes to Target stuff, I quickly get lost in the twisty 
> maze of little passages all different, so any suggestions here of (a) a 
> way to make this OS-based decision (b) in a way that DwarfDebug can query,
> would be very welcome.
> 
> - In each front-end/tool (not LLVM).  Again as noted above, this is not a 
> decision that front-ends/tools are making today, and adding this to their 
> list of responsibilities might be inappropriate.
> 
> Opinions about the appropriate way to do the defaulting?
> 
> Thanks,
> --paulr
>