> -----Original Message----- > From: Adrian Prantl [mailto:apra...@apple.com] > Sent: Friday, May 08, 2015 8:11 AM > To: Robinson, Paul > Cc: Eric Christopher; lldb-dev@cs.uiuc.edu; cfe-...@cs.uiuc.edu Developers > (cfe-...@cs.uiuc.edu); LLVM Developers Mailing List (llvm...@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_robin...@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 > _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
