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

Ted Woodward ted.woodward at codeaurora.org
Fri May 8 09:00:41 PDT 2015 

In some cases we do want to make the decision based on the target. For Hexagon, we don't support GDB anymore, only LLDB, so we always want LLDB tuning. The clang driver should have a way to specify that.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Adrian Prantl
Sent: Friday, May 08, 2015 10:11 AM
To: Robinson, Paul
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?


> 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


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list