> 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. > 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-boun...@cs.uiuc.edu [mailto:llvmdev-boun...@cs.uiuc.edu] On > Behalf Of Robinson, Paul > Sent: Wednesday, May 06, 2015 2:40 PM > To: Adrian Prantl; Eric Christopher > Cc: 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? > > @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:apra...@apple.com] > Sent: Wednesday, May 06, 2015 1:21 PM > To: Eric Christopher > Cc: Robinson, Paul; David Blaikie; lldb-dev@cs.uiuc.edu; cfe-...@cs.uiuc.edu > Developers (cfe-...@cs.uiuc.edu); LLVM Developers Mailing List > (llvm...@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 <echri...@gmail.com> wrote: > > Does the patch do all of this? > > -eric > > On Wed, May 6, 2015 at 1:18 PM Robinson, Paul > <paul_robin...@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-boun...@cs.uiuc.edu [mailto:llvmdev-boun...@cs.uiuc.edu] On > Behalf Of David Blaikie > Sent: Tuesday, May 05, 2015 8:21 PM > To: Adrian Prantl > Cc: lldb-dev@cs.uiuc.edu; Greg Clayton; cfe-...@cs.uiuc.edu Developers > (cfe-...@cs.uiuc.edu); LLVM Developers Mailing List (llvm...@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 <apra...@apple.com> wrote: > > On May 5, 2015, at 8:12 PM, David Blaikie <dblai...@gmail.com> wrote: > > > > On Tue, May 5, 2015 at 4:04 PM, Adrian Prantl <apra...@apple.com> wrote: > > > On May 1, 2015, at 2:18 PM, Greg Clayton <gclay...@apple.com> wrote: > > > > > >> On May 1, 2015, at 2:00 PM, Robinson, Paul > >> <paul_robin...@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_robin...@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@cs.uiuc.edu > >>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >> > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm...@cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > cfe-dev mailing list > cfe-...@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
