Robinson, Paul
2015-May-01 21:33 UTC
[LLVMdev] [cfe-dev] What does "debugger tuning" mean?
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." "not LLDB" wouldn't be "on for GDB only" (it'd be "on for GDB and SCE" given the current debuggers) Poorly phrased on my part. The "not Darwin" part would become "not LLDB" and _when combined with the existing "not SCE" part_ could be refactored into "on for GDB only." Re extra artificial entries, the specific example being variables for local anonymous unions: I was inclined to just say it's a debugger bug and only enable the workaround when targeting that debugger specifically, and Eric wasn't. We came to the conclusion/agreement that maybe having it on by defaut but off if targeting any /specific/ non-GDB debugger. Well, that's consistent with the default tuning being for GDB. Emitting it under GDB means you do get them by default but not if you're knowingly targeting something else. If you're envisioning a "no specific tuning" mode, I flip-flopped on that one a couple times while I was working up the idea, and came down on the side of not doing it. Not opposed to having it, but we haven't really thought about what it would look like. (Emit every kind of standard thing we know about, and no non-standard things at all? So we'd get pubnames and pubtypes and aranges but no Apple attributes or accelerator tables and not the GNU TLS opcode. Is that a useful mode to have?) Re where to put the guidelines: 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.) In the source, probably - somewhere near the enum or major entry point to querying it. By the definitions of the predicate functions, WFM. We might want to talk a bit more about when to err on the side of caution & put something in for every debugger by default, an opt out of it when tuning for a debugger that doesn't need it. That part of the visioning would imagine a new debugger (there are more of them out there in the world) and how to phrase the condition to work in the way, how to say this, least likely to be a problem. The TLS opcode should default to standard, except GDB. Soon enough I'll be using the tuning feature to turn off linkage names for SCE, but it'll be on by default. Like that. --paulr From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Friday, May 01, 2015 1:58 PM To: Robinson, Paul Cc: cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM Developers Mailing List (llvmdev at cs.uiuc.edu); lldb-dev at cs.uiuc.edu Subject: Re: [cfe-dev] What does "debugger tuning" mean? On Fri, 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." "not LLDB" wouldn't be "on for GDB only" (it'd be "on for GDB and SCE" given the current debuggers) Eric, Adrian, and I hit another case of positive/negative checking recently for some DWARF feature... local anonymous unions. GDB likes to have explicit (possibly artificial) local variables for the unions members, LLDB can manage without them. Eric & I discussed that there's a bit of a sliding scale of compatibility we should bother with - how much LLVM bends over backwards to cope with debugger bugs/limitations. I was inclined to just say it's a debugger bug and only enable the workaround when targeting that debugger specifically, and Eric wasn't. We came to the conclusion/agreement that maybe having it on by defaut but off if targeting any /specific/ non-GDB debugger. 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.) In the source, probably - somewhere near the enum or major entry point to querying it. We might want to talk a bit more about when to err on the side of caution & put something in for every debugger by default, an opt out of it when tuning for a debugger that doesn't need it. 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 _______________________________________________ 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/llvm-dev/attachments/20150501/46c4d913/attachment.html>
On Fri, May 1, 2015 at 2:33 PM, Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote:> 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." > > > "not LLDB" wouldn't be "on for GDB only" (it'd be "on for GDB and SCE" > given the current debuggers) > > Poorly phrased on my part. The "not Darwin" part would become "not > LLDB" and _when combined with the existing "not SCE" part_ could be > refactored into "on for GDB only." > > > > Re extra artificial entries, the specific example being variables for > local anonymous unions: > > > > I was inclined to just say it's a debugger bug and only enable the > workaround when targeting that debugger specifically, and Eric wasn't. We > came to the conclusion/agreement that maybe having it on by defaut but off > if targeting any /specific/ non-GDB debugger. > > Well, that's consistent with the default tuning being for GDB. >On Linux - presumably the default on Darwin will be LLDB and the default on ps4 will be SCE. That's probably fine. Though I'm sort of imagining that there might be things that could be a bit more aggressive if the user said "just GDB, hang the rest of them". But maybe we just don't need that option/functionality and the tuning will be the same as we have now based on architecture, nothing more aggressive than that. (well, maybe a little more aggressive, since we know that you can always force the debugger if you happen to be using a non-traditional debugger on the platform (the one we don't think is the common one for that platform) which is an option users don't have today)> Emitting it under GDB means you do get them by default but not if you're > knowingly targeting something else. > > > > If you're envisioning a "no specific tuning" mode, I flip-flopped on that > one a couple times while I was working up the idea, and came down on the > side of not doing it. Not opposed to having it, but we haven't really > thought about what it would look like. (Emit every kind of standard thing > we know about, and no non-standard things at all? So we'd get pubnames and > pubtypes and aranges but no Apple attributes or accelerator tables and not > the GNU TLS opcode. Is that a useful mode to have?) > > > > Re where to put the guidelines: > > > > 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.) > > > In the source, probably - somewhere near the enum or major entry point to > querying it. > > By the definitions of the predicate functions, WFM. > > > > We might want to talk a bit more about when to err on the side of caution > & put something in for every debugger by default, an opt out of it when > tuning for a debugger that doesn't need it. > > That part of the visioning would imagine a new debugger (there are more > of them out there in the world) and how to phrase the condition to work in > the way, how to say this, least likely to be a problem. The TLS opcode > should default to standard, except GDB. Soon enough I'll be using the > tuning feature to turn off linkage names for SCE, but it'll be on by > default. Like that. > > --paulr > > > > *From:* David Blaikie [mailto:dblaikie at gmail.com] > *Sent:* Friday, May 01, 2015 1:58 PM > *To:* Robinson, Paul > *Cc:* cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM > Developers Mailing List (llvmdev at cs.uiuc.edu); lldb-dev at cs.uiuc.edu > *Subject:* Re: [cfe-dev] What does "debugger tuning" mean? > > > > > > > > On Fri, 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." > > > "not LLDB" wouldn't be "on for GDB only" (it'd be "on for GDB and SCE" > given the current debuggers) > > Eric, Adrian, and I hit another case of positive/negative checking > recently for some DWARF feature... local anonymous unions. GDB likes to > have explicit (possibly artificial) local variables for the unions members, > LLDB can manage without them. > > Eric & I discussed that there's a bit of a sliding scale of compatibility > we should bother with - how much LLVM bends over backwards to cope with > debugger bugs/limitations. I was inclined to just say it's a debugger bug > and only enable the workaround when targeting that debugger specifically, > and Eric wasn't. We came to the conclusion/agreement that maybe having it > on by defaut but off if targeting any /specific/ non-GDB debugger. > > > 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.) > > > In the source, probably - somewhere near the enum or major entry point to > querying it. > > We might want to talk a bit more about when to err on the side of caution > & put something in for every debugger by default, an opt out of it when > tuning for a debugger that doesn't need it. > > > > 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 > > > _______________________________________________ > cfe-dev mailing list > 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/llvm-dev/attachments/20150501/451aba29/attachment.html>
Robinson, Paul
2015-May-01 22:12 UTC
[LLVMdev] [cfe-dev] What does "debugger tuning" mean?
I was inclined to just say it's a debugger bug and only enable the workaround when targeting that debugger specifically, and Eric wasn't. We came to the conclusion/agreement that maybe having it on by defaut but off if targeting any /specific/ non-GDB debugger. Well, that's consistent with the default tuning being for GDB. On Linux - presumably the default on Darwin will be LLDB and the default on ps4 will be SCE. You are so good at pointing out my loose thinking/phrasing… Yes, GDB remains the tuning we use if there's no command-line-specified tuning and the target isn't known to have some other debugger as its standard. So, the GDB special case of extra artificial variables will happen on platforms where we don't know any better. ☺ A separate "tuning" parameter also opens up defaulting to LLDB on targets other than Darwin; IIRC somebody said FreeBSD and possibly others have adopted LLDB as the standard debugger, so having LLVM learn better defaulting is even more goodness. --paulr From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Friday, May 01, 2015 2:48 PM To: Robinson, Paul; Eric Christopher Cc: cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM Developers Mailing List (llvmdev at cs.uiuc.edu); lldb-dev at cs.uiuc.edu Subject: Re: [cfe-dev] What does "debugger tuning" mean? On Fri, May 1, 2015 at 2:33 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote: 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." "not LLDB" wouldn't be "on for GDB only" (it'd be "on for GDB and SCE" given the current debuggers) Poorly phrased on my part. The "not Darwin" part would become "not LLDB" and _when combined with the existing "not SCE" part_ could be refactored into "on for GDB only." Re extra artificial entries, the specific example being variables for local anonymous unions: I was inclined to just say it's a debugger bug and only enable the workaround when targeting that debugger specifically, and Eric wasn't. We came to the conclusion/agreement that maybe having it on by defaut but off if targeting any /specific/ non-GDB debugger. Well, that's consistent with the default tuning being for GDB. On Linux - presumably the default on Darwin will be LLDB and the default on ps4 will be SCE. That's probably fine. Though I'm sort of imagining that there might be things that could be a bit more aggressive if the user said "just GDB, hang the rest of them". But maybe we just don't need that option/functionality and the tuning will be the same as we have now based on architecture, nothing more aggressive than that. (well, maybe a little more aggressive, since we know that you can always force the debugger if you happen to be using a non-traditional debugger on the platform (the one we don't think is the common one for that platform) which is an option users don't have today) Emitting it under GDB means you do get them by default but not if you're knowingly targeting something else. If you're envisioning a "no specific tuning" mode, I flip-flopped on that one a couple times while I was working up the idea, and came down on the side of not doing it. Not opposed to having it, but we haven't really thought about what it would look like. (Emit every kind of standard thing we know about, and no non-standard things at all? So we'd get pubnames and pubtypes and aranges but no Apple attributes or accelerator tables and not the GNU TLS opcode. Is that a useful mode to have?) Re where to put the guidelines: 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.) In the source, probably - somewhere near the enum or major entry point to querying it. By the definitions of the predicate functions, WFM. We might want to talk a bit more about when to err on the side of caution & put something in for every debugger by default, an opt out of it when tuning for a debugger that doesn't need it. That part of the visioning would imagine a new debugger (there are more of them out there in the world) and how to phrase the condition to work in the way, how to say this, least likely to be a problem. The TLS opcode should default to standard, except GDB. Soon enough I'll be using the tuning feature to turn off linkage names for SCE, but it'll be on by default. Like that. --paulr From: David Blaikie [mailto:dblaikie at gmail.com<mailto:dblaikie at gmail.com>] Sent: Friday, May 01, 2015 1:58 PM To: Robinson, Paul Cc: cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu> Developers (cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>); LLVM Developers Mailing List (llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>); lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu> Subject: Re: [cfe-dev] What does "debugger tuning" mean? On Fri, 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." "not LLDB" wouldn't be "on for GDB only" (it'd be "on for GDB and SCE" given the current debuggers) Eric, Adrian, and I hit another case of positive/negative checking recently for some DWARF feature... local anonymous unions. GDB likes to have explicit (possibly artificial) local variables for the unions members, LLDB can manage without them. Eric & I discussed that there's a bit of a sliding scale of compatibility we should bother with - how much LLVM bends over backwards to cope with debugger bugs/limitations. I was inclined to just say it's a debugger bug and only enable the workaround when targeting that debugger specifically, and Eric wasn't. We came to the conclusion/agreement that maybe having it on by defaut but off if targeting any /specific/ non-GDB debugger. 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.) In the source, probably - somewhere near the enum or major entry point to querying it. We might want to talk a bit more about when to err on the side of caution & put something in for every debugger by default, an opt out of it when tuning for a debugger that doesn't need it. 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 _______________________________________________ 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/llvm-dev/attachments/20150501/79b2b504/attachment.html>