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

Robinson, Paul Paul_Robinson at playstation.sony.com
Wed May 6 13:17:10 PDT 2015 

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<mailto:aprantl at apple.com>> wrote:

On May 5, 2015, at 8:12 PM, David Blaikie <dblaikie at gmail.com<mailto:dblaikie at gmail.com>> wrote:



On Tue, May 5, 2015 at 4:04 PM, Adrian Prantl <aprantl at apple.com<mailto:aprantl at apple.com>> wrote:

> On May 1, 2015, at 2:18 PM, Greg Clayton <gclayton at apple.com<mailto:gclayton at apple.com>> wrote:
>
>
>> On May 1, 2015, at 2:00 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto: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<mailto: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<http://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<mailto:lldb-dev at cs.uiuc.edu>
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>         http://llvm.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<mailto:cfe-dev at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150506/bd749d24/attachment.html>

More information about the cfe-dev mailing list