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
