What does "debugger tuning" mean?

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

What does "debugger tuning" mean?

Robinson, Paul-3
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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [lldb-dev] What does "debugger tuning" mean?

Greg Clayton
Sounds reasonable to me.

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.
- LLDB wants the .apple_XXX accelerator tables, GDB wants .debug_pubnames/.debug_pubtypes

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.

Greg

> On May 1, 2015, at 1:06 PM, Robinson, Paul <[hidden email]> 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
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: What does "debugger tuning" mean?

David Blaikie
In reply to this post by Robinson, Paul-3


On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul <[hidden email]> 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
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [lldb-dev] What does "debugger tuning" mean?

Robinson, Paul-3
In reply to this post by Greg Clayton
> 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.

> - 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
> <[hidden email]> 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
> > [hidden email]
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [lldb-dev] What does "debugger tuning" mean?

Greg Clayton

> On May 1, 2015, at 2:00 PM, Robinson, Paul <[hidden email]> 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.

>> - 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
>> <[hidden email]> 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
>>> [hidden email]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [lldb-dev] What does "debugger tuning" mean?

David Blaikie
In reply to this post by Robinson, Paul-3


On Fri, May 1, 2015 at 2:00 PM, Robinson, Paul <[hidden email]> 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.

the trick is to make the base class's vtable out of line (by having a key function):

struct base {
  virtual ~base();
};

struct derived : base {
};

derived d;

the DWARF for that file (on non-darwin) will contain a declaration for 'base' and a definition for 'derived'.

GCC does the same thing.
 

> - 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
> <[hidden email]> 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
> > [hidden email]
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev


_______________________________________________


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: What does "debugger tuning" mean?

Robinson, Paul-3
In reply to this post by David Blaikie

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:[hidden email]]
Sent: Friday, May 01, 2015 1:58 PM
To: Robinson, Paul
Cc: [hidden email] Developers ([hidden email]); LLVM Developers Mailing List ([hidden email]); [hidden email]
Subject: Re: [cfe-dev] What does "debugger tuning" mean?

 

 

 

On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul <[hidden email]> 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
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [lldb-dev] What does "debugger tuning" mean?

Robinson, Paul-3
In reply to this post by David Blaikie

the DWARF for that file (on non-darwin) will contain a declaration for 'base' and a definition for 'derived'.

Ah, okay I see it now.  So to answer Greg's question, yes that seems like an LLDB tuning thing.

--paulr

 

From: David Blaikie [mailto:[hidden email]]
Sent: Friday, May 01, 2015 2:22 PM
To: Robinson, Paul
Cc: Greg Clayton; [hidden email]; [hidden email] Developers ([hidden email]); LLVM Developers Mailing List ([hidden email])
Subject: Re: [cfe-dev] [lldb-dev] What does "debugger tuning" mean?

 

 

 

On Fri, May 1, 2015 at 2:00 PM, Robinson, Paul <[hidden email]> 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.


the trick is to make the base class's vtable out of line (by having a key function):

struct base {
  virtual ~base();
};

struct derived : base {
};

derived d;

the DWARF for that file (on non-darwin) will contain a declaration for 'base' and a definition for 'derived'.

GCC does the same thing.
 


> - 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
> <[hidden email]> 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
> > [hidden email]
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev


_______________________________________________

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: What does "debugger tuning" mean?

David Blaikie
In reply to this post by Robinson, Paul-3


On Fri, May 1, 2015 at 2:33 PM, Robinson, Paul <[hidden email]> 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:[hidden email]]
Sent: Friday, May 01, 2015 1:58 PM
To: Robinson, Paul
Cc: [hidden email] Developers ([hidden email]); LLVM Developers Mailing List ([hidden email]); [hidden email]
Subject: Re: [cfe-dev] What does "debugger tuning" mean?

 

 

 

On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul <[hidden email]> 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
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

 



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: What does "debugger tuning" mean?

Robinson, Paul-3

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. J

 

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:[hidden email]]
Sent: Friday, May 01, 2015 2:48 PM
To: Robinson, Paul; Eric Christopher
Cc: [hidden email] Developers ([hidden email]); LLVM Developers Mailing List ([hidden email]); [hidden email]
Subject: Re: [cfe-dev] What does "debugger tuning" mean?

 

 

 

On Fri, May 1, 2015 at 2:33 PM, Robinson, Paul <[hidden email]> 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:[hidden email]]
Sent: Friday, May 01, 2015 1:58 PM
To: Robinson, Paul
Cc: [hidden email] Developers ([hidden email]); LLVM Developers Mailing List ([hidden email]); [hidden email]
Subject: Re: [cfe-dev] What does "debugger tuning" mean?

 

 

 

On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul <[hidden email]> 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
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

 

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] What does "debugger tuning" mean?

Daniel Berlin
In reply to this post by Robinson, Paul-3
On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul
<[hidden email]> wrote:

>
> 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.

How is this not actually "we expect the debugger to want his described
as X, Y, and Z" instead of "we expect the debugger to by X or Y or Z".

Debuggers change over time.

GDB 4's level of support != GDB 5 != GDB6 != GDB7.

Heck, the same version of GDB on different platforms can be very
different (HP's GDB was very different, as was Apple's).

Do you plan on having "debugger tuning" flags for each of these?

I am having a lot of trouble understanding how this is about what
debuggers expect and not "ways of representing things".

Otherwise, i see you getting stuck introducing tons and tons of
debugger tunings, instead of people who want it to work a certain way
building an option profile consisting of
"--debugging-feature=use-tls-operator
--debugging-feature=explicit-anonymous-namespace", and getting exactly
what they want.

IE a year from now, somebody comes along with a version of GDB that
doesn't match what your current "tuning profile" is, and asks for it
to change.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] What does "debugger tuning" mean?

Robinson, Paul-3
> -----Original Message-----
> From: Daniel Berlin [mailto:[hidden email]]
> Sent: Friday, May 01, 2015 3:15 PM
> To: Robinson, Paul
> Cc: [hidden email] Developers ([hidden email]); LLVM Developers
> Mailing List ([hidden email]); [hidden email]
> Subject: Re: [LLVMdev] What does "debugger tuning" mean?
>
> On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul
> <[hidden email]> wrote:
>
> >
> > 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.
>
> How is this not actually "we expect the debugger to want his described
> as X, Y, and Z" instead of "we expect the debugger to by X or Y or Z".

Different ways of describing things let us reason about them in different
ways.  Are Cartesian coordinates a reason to reject polar coordinates?

> Debuggers change over time.

Well, they're software too.  They're allowed.

> GDB 4's level of support != GDB 5 != GDB6 != GDB7.
>
> Heck, the same version of GDB on different platforms can be very
> different (HP's GDB was very different, as was Apple's).
>
> Do you plan on having "debugger tuning" flags for each of these?

Are all of these current supported Clang/LLVM environments?  Are they
suffering because Clang currently emits DWARF in ways that cause them
problems, or that bloats the debug info unnecessarily?  Are vendors
carrying a pile of private patches to get LLVM to emit DWARF that looks
like what their debugger wants?  If the answer to these questions is
Yes then my answer to your question is Sure, we could, if we find
those differences to be important.

I promise you that these things are true at Sony, and I would be
astounded if it wasn't true for Apple. Guess what? LLDB and SCE are
two of the debugger-tuning options for a reason.

Show me another _real_ case of _real_ differences that matter to the
community, and we can talk about another debugger tuning option.

> I am having a lot of trouble understanding how this is about what
> debuggers expect and not "ways of representing things".

Sometimes there's not much difference in the result, although there
is a difference in how we think about it.

> Otherwise, i see you getting stuck introducing tons and tons of
> debugger tunings, instead of people who want it to work a certain way
> building an option profile consisting of
> "--debugging-feature=use-tls-operator
> --debugging-feature=explicit-anonymous-namespace", and getting exactly
> what they want.

(That sort of alternate proposal is way more useful than the straw-man
stuff you started out with.  Just sayin'.)

(Also incidentally, I see gcc 4.8.2 is emitting an explicit import of
anonymous namespaces, so that's becoming _less_ different over time.)

In fact this is more or less how DwarfDebug operates now; there is a
pile (small pile, but still a pile) of individual feature flags that
get set various ways depending on target or command-line options.
The problem I'm looking at is that the defaults for a lot of these
things are based on target, which AFAICT is based on an out-of-date
assumption about how target correlates to debugger.

I'm proposing to package up known sets of stuff that we're having to
contend with _today_ in a way that's easier to talk about and do
something about than the target-oriented mish-mash we have now.

It's a whole lot simpler to say something like "FreeBSD implies LLDB"
instead of "FreeBSD implies accelerator tables and standard TLS opcode
and no pubnames or pubtypes."

Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref
--lang-feature=move_ctor ..." than "-std=c++11"?


> IE a year from now, somebody comes along with a version of GDB that
> doesn't match what your current "tuning profile" is, and asks for it
> to change.

If it's meaningfully different, i.e. makes enough of a functional and/or
size difference, and it's an environment we collectively want to support,
and it's unreasonable to get the necessary effect some other way, then
sure, maybe we would want to invent a new tuning profile.

But, if it doesn't meet that bar, I don't see why we'd want to.
--paulr


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] What does "debugger tuning" mean?

David Blaikie


On Fri, May 1, 2015 at 4:57 PM, Robinson, Paul <[hidden email]> wrote:
> -----Original Message-----
> From: Daniel Berlin [mailto:[hidden email]]
> Sent: Friday, May 01, 2015 3:15 PM
> To: Robinson, Paul
> Cc: [hidden email] Developers ([hidden email]); LLVM Developers
> Mailing List ([hidden email]); [hidden email]
> Subject: Re: [LLVMdev] What does "debugger tuning" mean?
>
> On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul
> <[hidden email]> wrote:
>
> >
> > 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.
>
> How is this not actually "we expect the debugger to want his described
> as X, Y, and Z" instead of "we expect the debugger to by X or Y or Z".

Different ways of describing things let us reason about them in different
ways.  Are Cartesian coordinates a reason to reject polar coordinates?

> Debuggers change over time.

Well, they're software too.  They're allowed.

> GDB 4's level of support != GDB 5 != GDB6 != GDB7.
>
> Heck, the same version of GDB on different platforms can be very
> different (HP's GDB was very different, as was Apple's).
>
> Do you plan on having "debugger tuning" flags for each of these?

Are all of these current supported Clang/LLVM environments?  Are they
suffering because Clang currently emits DWARF in ways that cause them
problems, or that bloats the debug info unnecessarily?  Are vendors
carrying a pile of private patches to get LLVM to emit DWARF that looks
like what their debugger wants?  If the answer to these questions is
Yes then my answer to your question is Sure, we could, if we find
those differences to be important.

I promise you that these things are true at Sony, and I would be
astounded if it wasn't true for Apple.

FWIW I'd be surprised if Apple's carrying much internal cost for LLVM's debug info. It was essentially built for ye olde GDB and even when I set about improving it I brought up an external buildbot for that workload to ensure it wasn't broken (& LLDB was built for LLVM's debug info output, so there's not much reason to expect that wouldn't work - the base class declaration's one of the only cases there that I know of - and yes, that's predicated on Darwin & should be predicated on LLDB as you're proposing)
 
Guess what? LLDB and SCE are
two of the debugger-tuning options for a reason.

Show me another _real_ case of _real_ differences that matter to the
community, and we can talk about another debugger tuning option.

> I am having a lot of trouble understanding how this is about what
> debuggers expect and not "ways of representing things".

Sometimes there's not much difference in the result, although there
is a difference in how we think about it.

> Otherwise, i see you getting stuck introducing tons and tons of
> debugger tunings, instead of people who want it to work a certain way
> building an option profile consisting of
> "--debugging-feature=use-tls-operator
> --debugging-feature=explicit-anonymous-namespace", and getting exactly
> what they want.

(That sort of alternate proposal is way more useful than the straw-man
stuff you started out with.  Just sayin'.)

(Also incidentally, I see gcc 4.8.2 is emitting an explicit import of
anonymous namespaces, so that's becoming _less_ different over time.)

In fact this is more or less how DwarfDebug operates now; there is a
pile (small pile, but still a pile) of individual feature flags that
get set various ways depending on target or command-line options.
The problem I'm looking at is that the defaults for a lot of these
things are based on target, which AFAICT is based on an out-of-date
assumption about how target correlates to debugger.

I'm proposing to package up known sets of stuff that we're having to
contend with _today_ in a way that's easier to talk about and do
something about than the target-oriented mish-mash we have now.

It's a whole lot simpler to say something like "FreeBSD implies LLDB"
instead of "FreeBSD implies accelerator tables and standard TLS opcode
and no pubnames or pubtypes."

Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref
--lang-feature=move_ctor ..." than "-std=c++11"?


> IE a year from now, somebody comes along with a version of GDB that
> doesn't match what your current "tuning profile" is, and asks for it
> to change.

If it's meaningfully different, i.e. makes enough of a functional and/or
size difference, and it's an environment we collectively want to support,
and it's unreasonable to get the necessary effect some other way, then
sure, maybe we would want to invent a new tuning profile.

But, if it doesn't meet that bar, I don't see why we'd want to.
--paulr


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] What does "debugger tuning" mean?

Robinson, Paul-3

FWIW I'd be surprised if Apple's carrying much internal cost for LLVM's debug info.

 

Hmm maybe.  Adrian seemed awfully excited about the TLS opcode patch, though.

--paulr

 

From: David Blaikie [mailto:[hidden email]]
Sent: Friday, May 01, 2015 5:11 PM
To: Robinson, Paul
Cc: Daniel Berlin; [hidden email]; [hidden email] Developers ([hidden email]); LLVM Developers Mailing List ([hidden email])
Subject: Re: [cfe-dev] [LLVMdev] What does "debugger tuning" mean?

 

 

 

On Fri, May 1, 2015 at 4:57 PM, Robinson, Paul <[hidden email]> wrote:

> -----Original Message-----
> From: Daniel Berlin [mailto:[hidden email]]
> Sent: Friday, May 01, 2015 3:15 PM
> To: Robinson, Paul
> Cc: [hidden email] Developers ([hidden email]); LLVM Developers
> Mailing List ([hidden email]); [hidden email]
> Subject: Re: [LLVMdev] What does "debugger tuning" mean?
>
> On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul
> <[hidden email]> wrote:
>
> >
> > 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.
>
> How is this not actually "we expect the debugger to want his described
> as X, Y, and Z" instead of "we expect the debugger to by X or Y or Z".

Different ways of describing things let us reason about them in different
ways.  Are Cartesian coordinates a reason to reject polar coordinates?

> Debuggers change over time.

Well, they're software too.  They're allowed.

> GDB 4's level of support != GDB 5 != GDB6 != GDB7.
>
> Heck, the same version of GDB on different platforms can be very
> different (HP's GDB was very different, as was Apple's).
>
> Do you plan on having "debugger tuning" flags for each of these?

Are all of these current supported Clang/LLVM environments?  Are they
suffering because Clang currently emits DWARF in ways that cause them
problems, or that bloats the debug info unnecessarily?  Are vendors
carrying a pile of private patches to get LLVM to emit DWARF that looks
like what their debugger wants?  If the answer to these questions is
Yes then my answer to your question is Sure, we could, if we find
those differences to be important.

I promise you that these things are true at Sony, and I would be
astounded if it wasn't true for Apple.


FWIW I'd be surprised if Apple's carrying much internal cost for LLVM's debug info. It was essentially built for ye olde GDB and even when I set about improving it I brought up an external buildbot for that workload to ensure it wasn't broken (& LLDB was built for LLVM's debug info output, so there's not much reason to expect that wouldn't work - the base class declaration's one of the only cases there that I know of - and yes, that's predicated on Darwin & should be predicated on LLDB as you're proposing)
 

Guess what? LLDB and SCE are
two of the debugger-tuning options for a reason.

Show me another _real_ case of _real_ differences that matter to the
community, and we can talk about another debugger tuning option.

> I am having a lot of trouble understanding how this is about what
> debuggers expect and not "ways of representing things".

Sometimes there's not much difference in the result, although there
is a difference in how we think about it.

> Otherwise, i see you getting stuck introducing tons and tons of
> debugger tunings, instead of people who want it to work a certain way
> building an option profile consisting of
> "--debugging-feature=use-tls-operator
> --debugging-feature=explicit-anonymous-namespace", and getting exactly
> what they want.

(That sort of alternate proposal is way more useful than the straw-man
stuff you started out with.  Just sayin'.)

(Also incidentally, I see gcc 4.8.2 is emitting an explicit import of
anonymous namespaces, so that's becoming _less_ different over time.)

In fact this is more or less how DwarfDebug operates now; there is a
pile (small pile, but still a pile) of individual feature flags that
get set various ways depending on target or command-line options.
The problem I'm looking at is that the defaults for a lot of these
things are based on target, which AFAICT is based on an out-of-date
assumption about how target correlates to debugger.

I'm proposing to package up known sets of stuff that we're having to
contend with _today_ in a way that's easier to talk about and do
something about than the target-oriented mish-mash we have now.

It's a whole lot simpler to say something like "FreeBSD implies LLDB"
instead of "FreeBSD implies accelerator tables and standard TLS opcode
and no pubnames or pubtypes."

Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref
--lang-feature=move_ctor ..." than "-std=c++11"?


> IE a year from now, somebody comes along with a version of GDB that
> doesn't match what your current "tuning profile" is, and asks for it
> to change.

If it's meaningfully different, i.e. makes enough of a functional and/or
size difference, and it's an environment we collectively want to support,
and it's unreasonable to get the necessary effect some other way, then
sure, maybe we would want to invent a new tuning profile.

But, if it doesn't meet that bar, I don't see why we'd want to.

--paulr


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] What does "debugger tuning" mean?

Daniel Berlin
In reply to this post by Robinson, Paul-3
On Fri, May 1, 2015 at 4:57 PM, Robinson, Paul
<[hidden email]> wrote:

>> -----Original Message-----
>> From: Daniel Berlin [mailto:[hidden email]]
>> Sent: Friday, May 01, 2015 3:15 PM
>> To: Robinson, Paul
>> Cc: [hidden email] Developers ([hidden email]); LLVM Developers
>> Mailing List ([hidden email]); [hidden email]
>> Subject: Re: [LLVMdev] What does "debugger tuning" mean?
>>
>> On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul
>> <[hidden email]> wrote:
>>
>> >
>> > 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.
>>
>> How is this not actually "we expect the debugger to want his described
>> as X, Y, and Z" instead of "we expect the debugger to by X or Y or Z".
>
> Different ways of describing things let us reason about them in different
> ways.  Are Cartesian coordinates a reason to reject polar coordinates?
>

Paul.
I'm trying to understand why you've chosen the design you have.
Given that what you are designing is something that is likely to have
to be supported for a pretty long time, it makes sense to make sure
that design is the right one for the use case you are trying to
achieve.

>> Debuggers change over time.
>
> Well, they're software too.  They're allowed.
>
>> GDB 4's level of support != GDB 5 != GDB6 != GDB7.
>>
>> Heck, the same version of GDB on different platforms can be very
>> different (HP's GDB was very different, as was Apple's).
>>
>> Do you plan on having "debugger tuning" flags for each of these?
>
> Are all of these current supported Clang/LLVM environments?

Plenty of them are?

> Are they
> suffering because Clang currently emits DWARF in ways that cause them
> problems, or that bloats the debug info unnecessarily?

Yes, sure.

>  Are vendors
> carrying a pile of private patches to get LLVM to emit DWARF that looks
> like what their debugger wants?  If the answer to these questions is
> Yes then my answer to your question is Sure, we could, if we find
> those differences to be important.

This does not do a lot to explain why your design choice of "debugger
names" over "features" makes sense.


>
> I promise you that these things are true at Sony, and I would be
> astounded if it wasn't true for Apple. Guess what? LLDB and SCE are
> two of the debugger-tuning options for a reason.

What does this have to do anything?

If they were just features, you wouldn't have to define *any of these options*.

>
> Show me another _real_ case of _real_ differences that matter to the
> community, and we can talk about another debugger tuning option.

Again, i'm asking you to define why "debugger target" is the right
abstraction for what you are trying to achieve, when history has shown
1. Feature tests/description have worked better for compiler
differentiation than target "gcc 2.95"
2. The same is highly likely to be true of debuggers.

Particularly in light of the fact that what i'm suggesting you do does
not in any way prevent or change what you want to achieve, but simply
abstract it in a way that requires no work on the part of clang/llvm
to get any particular subset of features they want for their debugger.
IE people do not have to change source in response to debugger
changes.

In response, you have mostly just told me "a lot of users are in pain
right now".

>
>> I am having a lot of trouble understanding how this is about what
>> debuggers expect and not "ways of representing things".
>
> Sometimes there's not much difference in the result, although there
> is a difference in how we think about it.
>
>> Otherwise, i see you getting stuck introducing tons and tons of
>> debugger tunings, instead of people who want it to work a certain way
>> building an option profile consisting of
>> "--debugging-feature=use-tls-operator
>> --debugging-feature=explicit-anonymous-namespace", and getting exactly
>> what they want.
>
> (That sort of alternate proposal is way more useful than the straw-man
> stuff you started out with.  Just sayin'.)

Seriously?

It's not a strawman. I am asking you *why you have designed it this
way when plenty of other abstractions, at face value, seem to make
more sense to me"

>
> (Also incidentally, I see gcc 4.8.2 is emitting an explicit import of
> anonymous namespaces, so that's becoming _less_ different over time.)
>
> In fact this is more or less how DwarfDebug operates now; there is a
> pile (small pile, but still a pile) of individual feature flags that
> get set various ways depending on target or command-line options.
> The problem I'm looking at is that the defaults for a lot of these
> things are based on target, which AFAICT is based on an out-of-date
> assumption about how target correlates to debugger.
>
> I'm proposing to package up known sets of stuff that we're having to
> contend with _today_ in a way that's easier to talk about and do
> something about than the target-oriented mish-mash we have now.

>
> It's a whole lot simpler to say something like "FreeBSD implies LLDB"
> instead of "FreeBSD implies accelerator tables and standard TLS opcode
> and no pubnames or pubtypes."
>
> Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref
> --lang-feature=move_ctor ..." than "-std=c++11"?
The lang-feature stuff is exactly how people test for what level of
c++11 support something has.
-std=c++11, in fact, means different things to different compilers,
and thus, has in fact *not* provided a good abstraction for people
trying to say "i want to be able to compile anything that is standard
c++11".  Why do you expect debuggers to be different here?
Honestly. I'm really just trying to understand why you think debuggers
are going to turn out different.
This is despite the fact that C++11 is in fact a standard. If there
was "standard gdb", yes, it may make sense for llvm to *try* have
-debugger-std=gdb.  But there *is no standard gdb*.  So i'm trying to
understand why you are tying you design to the notion that you can
have a "gdb debugger tuning", instead of having a list of features,
and then having something that understands what the user wants (like
your IDE, or even a driver), set the feature flags that make sense for
whatever profiles you care to define.

>
>
>> IE a year from now, somebody comes along with a version of GDB that
>> doesn't match what your current "tuning profile" is, and asks for it
>> to change.
>
> If it's meaningfully different, i.e. makes enough of a functional and/or
> size difference, and it's an environment we collectively want to support,
> and it's unreasonable to get the necessary effect some other way, then
> sure, maybe we would want to invent a new tuning profile.
>
> But, if it doesn't meet that bar, I don't see why we'd want to.


None of this has been particularly helpful in understanding why you've
made the design tradeoffs you have.  I'm not calling your design good
or bad. I'm trying to understand why you have chosen this set of
things from among the various alternatives.

Is there a document, a thread, or anything that goes through the
various alternatives you've considered before you arrived at this one?

> --paulr
>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] What does "debugger tuning" mean?

Sean Silva
In reply to this post by Robinson, Paul-3


On Fri, May 1, 2015 at 4:57 PM, Robinson, Paul <[hidden email]> wrote:
> -----Original Message-----
> From: Daniel Berlin [mailto:[hidden email]]
> Sent: Friday, May 01, 2015 3:15 PM
> To: Robinson, Paul
> Cc: [hidden email] Developers ([hidden email]); LLVM Developers
> Mailing List ([hidden email]); [hidden email]
> Subject: Re: [LLVMdev] What does "debugger tuning" mean?
>
> On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul
> <[hidden email]> wrote:
>
> >
> > 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.
>
> How is this not actually "we expect the debugger to want his described
> as X, Y, and Z" instead of "we expect the debugger to by X or Y or Z".

Different ways of describing things let us reason about them in different
ways.  Are Cartesian coordinates a reason to reject polar coordinates?

> Debuggers change over time.

Well, they're software too.  They're allowed.

> GDB 4's level of support != GDB 5 != GDB6 != GDB7.
>
> Heck, the same version of GDB on different platforms can be very
> different (HP's GDB was very different, as was Apple's).
>
> Do you plan on having "debugger tuning" flags for each of these?

Are all of these current supported Clang/LLVM environments?  Are they
suffering because Clang currently emits DWARF in ways that cause them
problems, or that bloats the debug info unnecessarily?  Are vendors
carrying a pile of private patches to get LLVM to emit DWARF that looks
like what their debugger wants?  If the answer to these questions is
Yes then my answer to your question is Sure, we could, if we find
those differences to be important.

I promise you that these things are true at Sony, and I would be
astounded if it wasn't true for Apple. Guess what? LLDB and SCE are
two of the debugger-tuning options for a reason.

Show me another _real_ case of _real_ differences that matter to the
community, and we can talk about another debugger tuning option.

> I am having a lot of trouble understanding how this is about what
> debuggers expect and not "ways of representing things".

Sometimes there's not much difference in the result, although there
is a difference in how we think about it.

> Otherwise, i see you getting stuck introducing tons and tons of
> debugger tunings, instead of people who want it to work a certain way
> building an option profile consisting of
> "--debugging-feature=use-tls-operator
> --debugging-feature=explicit-anonymous-namespace", and getting exactly
> what they want.

(That sort of alternate proposal is way more useful than the straw-man
stuff you started out with.  Just sayin'.)

(Also incidentally, I see gcc 4.8.2 is emitting an explicit import of
anonymous namespaces, so that's becoming _less_ different over time.)

In fact this is more or less how DwarfDebug operates now; there is a
pile (small pile, but still a pile) of individual feature flags that
get set various ways depending on target or command-line options.
The problem I'm looking at is that the defaults for a lot of these
things are based on target, which AFAICT is based on an out-of-date
assumption about how target correlates to debugger.

I'm proposing to package up known sets of stuff that we're having to
contend with _today_ in a way that's easier to talk about and do
something about than the target-oriented mish-mash we have now.

It's a whole lot simpler to say something like "FreeBSD implies LLDB"
instead of "FreeBSD implies accelerator tables and standard TLS opcode
and no pubnames or pubtypes."

Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref
--lang-feature=move_ctor ..." than "-std=c++11"?

Is there a reason that we couldn't implement "--debugger-target=lldb" as syntax sugar for "--debugger-feature=acceleratortables --debugger-feature=standardtlsopcode --debugger-feature=no-pubnames --debugger-feature=no-pubtypes"?

I'm not strongly convinced that we would necessarily need to expose the --debugger-feature flag to users (or at all on the command line), if that's what is bothering you. But at some point inside the code there needs to be an explicit factorization of the different "debugger targets" into what would be individual --debugger-feature options, so that it is easy to describe new debugger targets.

-- Sean Silva
 


> IE a year from now, somebody comes along with a version of GDB that
> doesn't match what your current "tuning profile" is, and asks for it
> to change.

If it's meaningfully different, i.e. makes enough of a functional and/or
size difference, and it's an environment we collectively want to support,
and it's unreasonable to get the necessary effect some other way, then
sure, maybe we would want to invent a new tuning profile.

But, if it doesn't meet that bar, I don't see why we'd want to.
--paulr


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] What does "debugger tuning" mean?

Robinson, Paul-3

Hi Daniel, your post came across as snarkier than that, apologies for the mis-interpretation.

 

My design tries to improve on a not-very-smooth situation today, where there is already "tuning" but it is based largely on the target—even though we know for a fact that target is not always a good proxy for choosing the expected debugger.  By making the expected debugger explicit, we separate these concerns, and clarify the intent.  The existing tuning has default behavior clearly intended to support GDB, LLDB, and now the SCE (PS4) debugger; therefore, my proposal made those three cases explicit.  If you have examples of other debuggers on other target, where emitting different subsets of DWARF would be beneficial, and those subsets don't align with GDB, LLDB, or SCE debugger, then more cases might be appropriate.  I am not inclined to propose hypothetical cases, but if you have actual examples then that would be very helpful.

Note that we are not talking about whether the debugger is different.  We are talking about whether the debug-info ought to be different.  Saying that some target has a different debugger is not sufficient.  If HP's wacky GDB, or OpenVMS Debug, or whatever, are happy with the DWARF we provide now, then there's no point to defining a new debugger-tuning case for them.

 

Regarding fine-grained feature-oriented command-line control, I thought I had said that in fact most of the specific cases already have that, although the naming isn't as consistent as one might like.  All of that folds down into individual feature-flags within the DwarfDebug class, whose constructor currently bases its defaults on the target and in my design would base its defaults on the debugger-tuning parameter.  Then the methods that actually emit DWARF look at the feature flags, not at the tuning parameter.

This situation is very close to what Sean said, where the debugger-tuning parameter provides a prepackaged set of feature-flags defaults. Any of these (that have their own command-line option) would be superseded by the explicit command-line option.

In some cases these individual features are exposed all the way out to the user command line.  This is especially true when you're talking about emitting or omitting entire sections, or a major less-well-supported feature like type units.  I am not eager to expose the more fiddly-bit things on the command line, because it's hard to envision any real value to it.

 

So, in those terms, what would the initial state of things be?

GDB = -generate-dwarf-pub-sections; (no command-line option) UseGNUTLSOpcode

LLDB = -dwarf-accel-tables

SCE = (none of the above)

 

I anticipate adding a new feature-flag, something like "-dwarf-linkage-names" to GDB and LLDB but not SCE, because SCE has no use for them.

I anticipate adding a new feature-flag to control the DW_AT_APPLE_* attributes, although whether its default should be target-based or tuning-based is TBD (I don't know the intended consumer of these attributes).

I anticipate changing the default for "-generate-arange-section" from always-false to Target==PS4CPU.  This is not under tuning control because the consumer of it on PS4 is not the debugger. In fact the default might end up being set in the driver, because there is an existing user command-line option for this.

If somebody wanted a command-line flag for UseGNUTLSOpcode, patches welcome.

 

If people want to bikeshed the backend command-line option names, that's a different discussion.  There are more existing options than the ones I've mentioned here; the others are default-off and under user command-line control.  Harmonizing all of them would be its own mini-project.

 

Does that help?

--paulr

 

From: Sean Silva [mailto:[hidden email]]
Sent: Friday, May 01, 2015 6:21 PM
To: Robinson, Paul
Cc: Daniel Berlin; [hidden email]; [hidden email] Developers ([hidden email]); LLVM Developers Mailing List ([hidden email])
Subject: Re: [cfe-dev] [LLVMdev] What does "debugger tuning" mean?

 

 

 

On Fri, May 1, 2015 at 4:57 PM, Robinson, Paul <[hidden email]> wrote:

> -----Original Message-----
> From: Daniel Berlin [mailto:[hidden email]]
> Sent: Friday, May 01, 2015 3:15 PM
> To: Robinson, Paul
> Cc: [hidden email] Developers ([hidden email]); LLVM Developers
> Mailing List ([hidden email]); [hidden email]
> Subject: Re: [LLVMdev] What does "debugger tuning" mean?
>
> On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul
> <[hidden email]> wrote:
>
> >
> > 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.
>
> How is this not actually "we expect the debugger to want his described
> as X, Y, and Z" instead of "we expect the debugger to by X or Y or Z".

Different ways of describing things let us reason about them in different
ways.  Are Cartesian coordinates a reason to reject polar coordinates?

> Debuggers change over time.

Well, they're software too.  They're allowed.

> GDB 4's level of support != GDB 5 != GDB6 != GDB7.
>
> Heck, the same version of GDB on different platforms can be very
> different (HP's GDB was very different, as was Apple's).
>
> Do you plan on having "debugger tuning" flags for each of these?

Are all of these current supported Clang/LLVM environments?  Are they
suffering because Clang currently emits DWARF in ways that cause them
problems, or that bloats the debug info unnecessarily?  Are vendors
carrying a pile of private patches to get LLVM to emit DWARF that looks
like what their debugger wants?  If the answer to these questions is
Yes then my answer to your question is Sure, we could, if we find
those differences to be important.

I promise you that these things are true at Sony, and I would be
astounded if it wasn't true for Apple. Guess what? LLDB and SCE are
two of the debugger-tuning options for a reason.

Show me another _real_ case of _real_ differences that matter to the
community, and we can talk about another debugger tuning option.

> I am having a lot of trouble understanding how this is about what
> debuggers expect and not "ways of representing things".

Sometimes there's not much difference in the result, although there
is a difference in how we think about it.

> Otherwise, i see you getting stuck introducing tons and tons of
> debugger tunings, instead of people who want it to work a certain way
> building an option profile consisting of
> "--debugging-feature=use-tls-operator
> --debugging-feature=explicit-anonymous-namespace", and getting exactly
> what they want.

(That sort of alternate proposal is way more useful than the straw-man
stuff you started out with.  Just sayin'.)

(Also incidentally, I see gcc 4.8.2 is emitting an explicit import of
anonymous namespaces, so that's becoming _less_ different over time.)

In fact this is more or less how DwarfDebug operates now; there is a
pile (small pile, but still a pile) of individual feature flags that
get set various ways depending on target or command-line options.
The problem I'm looking at is that the defaults for a lot of these
things are based on target, which AFAICT is based on an out-of-date
assumption about how target correlates to debugger.

I'm proposing to package up known sets of stuff that we're having to
contend with _today_ in a way that's easier to talk about and do
something about than the target-oriented mish-mash we have now.

It's a whole lot simpler to say something like "FreeBSD implies LLDB"
instead of "FreeBSD implies accelerator tables and standard TLS opcode
and no pubnames or pubtypes."

Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref
--lang-feature=move_ctor ..." than "-std=c++11"?

 

Is there a reason that we couldn't implement "--debugger-target=lldb" as syntax sugar for "--debugger-feature=acceleratortables --debugger-feature=standardtlsopcode --debugger-feature=no-pubnames --debugger-feature=no-pubtypes"?

 

I'm not strongly convinced that we would necessarily need to expose the --debugger-feature flag to users (or at all on the command line), if that's what is bothering you. But at some point inside the code there needs to be an explicit factorization of the different "debugger targets" into what would be individual --debugger-feature options, so that it is easy to describe new debugger targets.

 

-- Sean Silva

 



> IE a year from now, somebody comes along with a version of GDB that
> doesn't match what your current "tuning profile" is, and asks for it
> to change.

If it's meaningfully different, i.e. makes enough of a functional and/or
size difference, and it's an environment we collectively want to support,
and it's unreasonable to get the necessary effect some other way, then
sure, maybe we would want to invent a new tuning profile.

But, if it doesn't meet that bar, I don't see why we'd want to.

--paulr


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] What does "debugger tuning" mean?

Chris Lattner

On May 4, 2015, at 11:11 AM, Robinson, Paul <[hidden email]> wrote:
 
My design tries to improve on a not-very-smooth situation today, where there is already "tuning" but it is based largely on the target—even though we know for a fact that target is not always a good proxy for choosing the expected debugger.  By making the expected debugger explicit, we separate these concerns, and clarify the intent.  The existing tuning has default behavior clearly intended to support GDB, LLDB, and now the SCE (PS4) debugger; therefore, my proposal made those three cases explicit.  

FWIW, I agree with this rationale.  The question isn’t whether debugger tuning is good/bad or necessary/unnecessary.  It is apparently necessary, and the question is how to best factor it in the compiler.  Making this be explicit based on the debugger does seem a lot more preferable to me than implicitly tied to the target.

The platform integrator can then set the default for their target, but allow the user to override it if they want to do something unusual.

-Chris


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [LLVMdev] What does "debugger tuning" mean?

Daniel Berlin
In reply to this post by Robinson, Paul-3
On Mon, May 4, 2015 at 11:11 AM, Robinson, Paul
<[hidden email]> wrote:
> Hi Daniel, your post came across as snarkier than that, apologies for the
> mis-interpretation.

Sorry if it came off as snarky, as I said, i was just trying to
understand the rationale.

>
>
>
> My design tries to improve on a not-very-smooth situation today, where there
> is already "tuning" but it is based largely on the target—even though we
> know for a fact that target is not always a good proxy for choosing the
> expected debugger.  By making the expected debugger explicit, we separate
> these concerns, and clarify the intent.  The existing tuning has default
> behavior clearly intended to support GDB, LLDB, and now the SCE (PS4)
> debugger; therefore, my proposal made those three cases explicit.  If you
> have examples of other debuggers on other target, where emitting different
> subsets of DWARF would be beneficial, and those subsets don't align with
> GDB, LLDB, or SCE debugger, then more cases might be appropriate.  I am not
> inclined to propose hypothetical cases, but if you have actual examples then
> that would be very helpful.
>
> Note that we are not talking about whether the debugger is different.  We
> are talking about whether the debug-info ought to be different.

I understand.  For background, I used to maintain DWARF2/3 debug info
generation for GCC, and at one point, DWARF reading  and C++ support
for GDB :)
 So i am sadly, quite familiar with the state of the world here.



>  Saying that
> some target has a different debugger is not sufficient.
Sure, I understand.
Targets do not have debuggers. People have debuggers :)

>  If HP's wacky GDB,
> or OpenVMS Debug, or whatever, are happy with the DWARF we provide now, then
> there's no point to defining a new debugger-tuning case for them.

You've already said GDB isn't, and SCE's debugger isn't.  Do you
expect SCE's debugger will stay the same forever in terms of what
DWARF it wants?
(As i've said, repeatedly, GDB hasn't. I am happy to provide specific
examples if you like).

If not, what exactly does --debugger-tuning=sce actually mean?

Past that, as long as you are implementing this in terms of underlying
feature-controls, instead of

if (debuggertuning == SCE)
do this

*in the debug info generation code*

instead of something like

if (debuggertuning == SCE)
  set these DWARF generation  flags

in the driver code


if (DWARF generation flag set)
generate DWARF that looks one way
else
generate DWARF that looks another.

>
>
> Regarding fine-grained feature-oriented command-line control, I thought I
> had said that in fact most of the specific cases already have that, although
> the naming isn't as consistent as one might like.

I actually am not as concerned with the command line, as I am with how
this gets actually implemented.


>  All of that folds down
> into individual feature-flags within the DwarfDebug class, whose constructor
> currently bases its defaults on the target and in my design would base its
> defaults on the debugger-tuning parameter.  Then the methods that actually
> emit DWARF look at the feature flags, not at the tuning parameter.
>

This was the part i really wanted to know :)

> This situation is very close to what Sean said, where the debugger-tuning
> parameter provides a prepackaged set of feature-flags defaults. Any of these
> (that have their own command-line option) would be superseded by the
> explicit command-line option.

Sounds reasonable to me then :)

>
> In some cases these individual features are exposed all the way out to the
> user command line.  This is especially true when you're talking about
> emitting or omitting entire sections, or a major less-well-supported feature
> like type units.  I am not eager to expose the more fiddly-bit things on the
> command line, because it's hard to envision any real value to it.
>
>
>
> So, in those terms, what would the initial state of things be?
>
> GDB = -generate-dwarf-pub-sections; (no command-line option) UseGNUTLSOpcode
>
> LLDB = -dwarf-accel-tables
>
> SCE = (none of the above)
>
>
>
> I anticipate adding a new feature-flag, something like
> "-dwarf-linkage-names" to GDB and LLDB but not SCE, because SCE has no use
> for them.
>
> I anticipate adding a new feature-flag to control the DW_AT_APPLE_*
> attributes, although whether its default should be target-based or
> tuning-based is TBD (I don't know the intended consumer of these
> attributes).
>
> I anticipate changing the default for "-generate-arange-section" from
> always-false to Target==PS4CPU.  This is not under tuning control because
> the consumer of it on PS4 is not the debugger. In fact the default might end
> up being set in the driver, because there is an existing user command-line
> option for this.
>
> If somebody wanted a command-line flag for UseGNUTLSOpcode, patches welcome.
>
>
>
> If people want to bikeshed the backend command-line option names, that's a
> different discussion.  There are more existing options than the ones I've
> mentioned here; the others are default-off and under user command-line
> control.  Harmonizing all of them would be its own mini-project.
>
>
>
> Does that help?

Yes, tremendously.

Thanks for walking through this and explaining it to me ;)

>
> --paulr
>
>
>
> From: Sean Silva [mailto:[hidden email]]
> Sent: Friday, May 01, 2015 6:21 PM
> To: Robinson, Paul
> Cc: Daniel Berlin; [hidden email]; [hidden email] Developers
> ([hidden email]); LLVM Developers Mailing List ([hidden email])
> Subject: Re: [cfe-dev] [LLVMdev] What does "debugger tuning" mean?
>
>
>
>
>
>
>
> On Fri, May 1, 2015 at 4:57 PM, Robinson, Paul
> <[hidden email]> wrote:
>
>> -----Original Message-----
>> From: Daniel Berlin [mailto:[hidden email]]
>> Sent: Friday, May 01, 2015 3:15 PM
>> To: Robinson, Paul
>> Cc: [hidden email] Developers ([hidden email]); LLVM Developers
>> Mailing List ([hidden email]); [hidden email]
>> Subject: Re: [LLVMdev] What does "debugger tuning" mean?
>>
>> On Fri, May 1, 2015 at 1:06 PM, Robinson, Paul
>> <[hidden email]> wrote:
>>
>> >
>> > 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.
>>
>> How is this not actually "we expect the debugger to want his described
>> as X, Y, and Z" instead of "we expect the debugger to by X or Y or Z".
>
> Different ways of describing things let us reason about them in different
> ways.  Are Cartesian coordinates a reason to reject polar coordinates?
>
>> Debuggers change over time.
>
> Well, they're software too.  They're allowed.
>
>> GDB 4's level of support != GDB 5 != GDB6 != GDB7.
>>
>> Heck, the same version of GDB on different platforms can be very
>> different (HP's GDB was very different, as was Apple's).
>>
>> Do you plan on having "debugger tuning" flags for each of these?
>
> Are all of these current supported Clang/LLVM environments?  Are they
> suffering because Clang currently emits DWARF in ways that cause them
> problems, or that bloats the debug info unnecessarily?  Are vendors
> carrying a pile of private patches to get LLVM to emit DWARF that looks
> like what their debugger wants?  If the answer to these questions is
> Yes then my answer to your question is Sure, we could, if we find
> those differences to be important.
>
> I promise you that these things are true at Sony, and I would be
> astounded if it wasn't true for Apple. Guess what? LLDB and SCE are
> two of the debugger-tuning options for a reason.
>
> Show me another _real_ case of _real_ differences that matter to the
> community, and we can talk about another debugger tuning option.
>
>> I am having a lot of trouble understanding how this is about what
>> debuggers expect and not "ways of representing things".
>
> Sometimes there's not much difference in the result, although there
> is a difference in how we think about it.
>
>> Otherwise, i see you getting stuck introducing tons and tons of
>> debugger tunings, instead of people who want it to work a certain way
>> building an option profile consisting of
>> "--debugging-feature=use-tls-operator
>> --debugging-feature=explicit-anonymous-namespace", and getting exactly
>> what they want.
>
> (That sort of alternate proposal is way more useful than the straw-man
> stuff you started out with.  Just sayin'.)
>
> (Also incidentally, I see gcc 4.8.2 is emitting an explicit import of
> anonymous namespaces, so that's becoming _less_ different over time.)
>
> In fact this is more or less how DwarfDebug operates now; there is a
> pile (small pile, but still a pile) of individual feature flags that
> get set various ways depending on target or command-line options.
> The problem I'm looking at is that the defaults for a lot of these
> things are based on target, which AFAICT is based on an out-of-date
> assumption about how target correlates to debugger.
>
> I'm proposing to package up known sets of stuff that we're having to
> contend with _today_ in a way that's easier to talk about and do
> something about than the target-oriented mish-mash we have now.
>
> It's a whole lot simpler to say something like "FreeBSD implies LLDB"
> instead of "FreeBSD implies accelerator tables and standard TLS opcode
> and no pubnames or pubtypes."
>
> Or would you rather say "--lang-feature=auto --lang-feature=rvalue-ref
> --lang-feature=move_ctor ..." than "-std=c++11"?
>
>
>
> Is there a reason that we couldn't implement "--debugger-target=lldb" as
> syntax sugar for "--debugger-feature=acceleratortables
> --debugger-feature=standardtlsopcode --debugger-feature=no-pubnames
> --debugger-feature=no-pubtypes"?
>
>
>
> I'm not strongly convinced that we would necessarily need to expose the
> --debugger-feature flag to users (or at all on the command line), if that's
> what is bothering you. But at some point inside the code there needs to be
> an explicit factorization of the different "debugger targets" into what
> would be individual --debugger-feature options, so that it is easy to
> describe new debugger targets.
>
>
>
> -- Sean Silva
>
>
>
>
>
>> IE a year from now, somebody comes along with a version of GDB that
>> doesn't match what your current "tuning profile" is, and asks for it
>> to change.
>
> If it's meaningfully different, i.e. makes enough of a functional and/or
> size difference, and it's an environment we collectively want to support,
> and it's unreasonable to get the necessary effect some other way, then
> sure, maybe we would want to invent a new tuning profile.
>
> But, if it doesn't meet that bar, I don't see why we'd want to.
>
> --paulr
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Adrian Prantl
In reply to this post by Greg Clayton

> On May 1, 2015, at 2:18 PM, Greg Clayton <[hidden email]> wrote:
>
>
>> On May 1, 2015, at 2:00 PM, Robinson, Paul <[hidden email]> 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 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
>>> <[hidden email]> 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
>>>> [hidden email]
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
12