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

[Robinson, Paul]

> -----Original Message-----
> From: Adrian Prantl [mailto:aprantl at apple.com]
> Sent: Friday, May 08, 2015 8:11 AM
> To: Robinson, Paul
> Cc: Eric Christopher; 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.

The Apple accelerator tables already have a feature-flag in DwarfDebug, and
I'd like to add one for the DW_AT_APPLE attributes.  When the DwarfDebug ctor
unpacks the tuning option to set default values of feature flags, it could 
certainly be done as (isDarwin() || tuneForLLDB()).
--paulr

> 
> > 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
>