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

Adrian Prantl aprantl at apple.com
Fri May 8 08:10:59 PDT 2015 

> 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

More information about the llvm-dev mailing list