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

> On May 5, 2015, at 8:12 PM, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> 
> 
> On Tue, May 5, 2015 at 4:04 PM, Adrian Prantl <aprantl at apple.com
<mailto:aprantl at apple.com>> wrote:
> 
> > On May 1, 2015, at 2:18 PM, Greg Clayton <gclayton at apple.com
<mailto:gclayton at apple.com>> wrote:
> >
> >
> >> On May 1, 2015, at 2:00 PM, Robinson, Paul <Paul_Robinson at
playstation.sony.com <mailto:Paul_Robinson at playstation.sony.com>>
wrote:
> >>
> >>> A few more things that vote for debugger tuning:
> >>>
> >>> - LLDB doesn't like to have DWARF that has a class A that
inherits from
> >>> class B, but only a forward declaration of class B is
provided.
> >>
> >> Hmm do we emit that kind of thing today?  In a naïve test, I'm
seeing
> >> the full description of class B.
> >
> > by default for darwin, it doesn't do this. For others you must
specify -fno-limit-debug-info or some flag like that.
> 
> I think the option is -f(no-)standalone-debug-info
> 
> -fno-limit-debug-info == -fstandalone-debug
> (limit-debug-info was the old name & we had a long discussion and
decided standalone-debug more aptly described what it should mean/how it should
generalize)
And if my memory serves correctly, what adds to the confusion is that
-flimit-debug-info used to do more than just this particular optimization, but
we decided that most of the other optimizations weren’t really helpful, so they
were removed.
>  
> which only emits full definitions of classes in the object file that holds
and object’s vtable.
> 
> -- adrian
> >
> >>> - LLDB wants the .apple_XXX accelerator tables, GDB wants
> >>> .debug_pubnames/.debug_pubtypes
> >>
> >> Agreed.
> >>
> >>> So it would be great to have a "-debugger" flag that
could be specified
> >>>
> >>> -debugger=lldb
> >>> -debugger=gdb
> >>>
> >>> Not sure on the option name, but I do like the idea.
> >>
> >> We'll bikeshed the name later but yes, that's the plan.
> >> Thanks,
> >> --paulr
> >>
> >>>
> >>> Greg
> >>>
> >>>> On May 1, 2015, at 1:06 PM, Robinson, Paul
> >>> <Paul_Robinson at playstation.sony.com
<mailto:Paul_Robinson at playstation.sony.com>> wrote:
> >>>>
> >>>> This is basically a reboot of the previous thread titled
> >>>> About the "debugger target"
> >>>> except that "target" was really too strong a
term for what I had
> >>> intended
> >>>> to use this feature for.  "Debugger tuning" is
more like it.  You don't
> >>>> need to have read the previous thread, I'll recap
here.
> >>>>
> >>>> Fundamentally, Clang/LLVM uses DWARF as the specification
for the
> >>> _format_
> >>>> of information provided by the compiler to a variety of
"consumers,"
> >>> which
> >>>> primarily means debuggers (but not exclusively).  [For a
long time it
> >>> was
> >>>> the only format supported by LLVM. Lately, Microsoft debug
info has
> >>> started
> >>>> appearing, but being a less widely used format, the issues
that DWARF
> >>> runs
> >>>> into aren't a concern for that format.  So
"debugger tuning" is unlikely
> >>>> to be an issue for Microsoft debug info.]
> >>>>
> >>>> DWARF is a permissive standard, meaning that it does not
rigidly require
> >>>> that source-language construct X must be described using
the DWARF
> >>>> construct Y.  Instead, DWARF says something more like,
"If you have a
> >>>> source construct that means something like X, here's a
mechanism Y that
> >>>> you could use to describe it."  While this gives
compilers a lot of nice
> >>>> flexibility, it does mean that there's a lot of wiggle
room for how a
> >>>> compiler describes something and in how a debugger
interprets that
> >>>> description.  Compilers and debuggers therefore need to do
a bit of
> >>>> negotiation in determining how the debug-info
"contract" will work, when
> >>>> it comes to nitty-gritty details.  DWARF itself (the
standard, as well
> >>>> as the committee that owns the standard) refuses to get
involved in this
> >>>> negotiation, referring to all that as "quality of
implementation
> >>> issues."
> >>>>
> >>>> It is readily apparent that different debuggers have
different ideas
> >>>> about certain DWARF features, for example whether they are
useful or
> >>>> irrelevant, or whether a certain source construct should
be described
> >>>> this way or that way.  As these generally fall into the
QOI realm, the
> >>>> DWARF spec itself is no help, and it comes down to a
matter of opinion
> >>>> about whether "the debugger should just know
this" or "the compiler
> >>>> really ought to just emit it that way."
> >>>>
> >>>> Clang/LLVM is in the position of being a compiler that
wants to support
> >>>> several different debuggers, all of which have slightly
different ideas
> >>>> about what they want from the DWARF info for a program. 
Our first line
> >>>> of defense of course is the DWARF standard itself, but as
we've seen,
> >>>> that is not a universally definitive reference.
> >>>>
> >>>> LLVM already emits DWARF slightly differently for
different *targets*;
> >>>> primarily Darwin, in a few cases PS4.  But in at least
some cases, the
> >>>> target is just a (somewhat unreliable) proxy for which
*debugger* the
> >>>> compiler expects to be consuming the DWARF.  The most
instructive case
> >>>> is the exact DWARF expression used to describe the
location of a thread-
> >>>> local variable.  DWARF v3 defined an operator to find the
base address
> >>>> of the thread-local storage area; however, GDB has never
learned to
> >>>> recognize it.  Therefore, for targets where we
"know" GDB isn't used,
> >>>> we can emit the standard operator; for targets where GDB
*might* be
> >>>> used, we need to emit the equivalent (non-standard) GNU
operator.
> >>>>
> >>>> It would be semantically more meaningful to base decisions
like this on
> >>>> whether we expected the debugger to be X or Y or Z. 
Therefore I've
> >>>> proposed (http://reviews.llvm.org/D8506
<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
<http://llvm.org/>, but it's on the list.
> >>>> I would conditionalize this on the target, not the
debugger, because
> >>>> the debugger is not why we want to generate the section.
> >>>>
> >>>> Okay, so I've been pretty long-winded about all this,
can I possibly
> >>>> codify it all into a reasonably succinct set of
guidelines?  (which
> >>>> ought to be committed to the repo somewhere, although
whether it's as
> >>>> a lump of text in a docs webpage or a lump of commentary
in some source
> >>>> file is not clear; opinions welcome.)
> >>>>
> >>>> o Emit standard DWARF if possible.
> >>>> o Omitting standard DWARF features that nobody uses is
fine.
> >>>> (example: DW_AT_sibling)
> >>>> o Extensions are okay, but think about the circumstances
where they
> >>>> would be useful (versus just wasting space).  These are
probably a
> >>>> debugger tuning decision, but might be a target-based
decision.
> >>>> (example: DW_AT_APPLE_* attributes)
> >>>> o If some debugger can't tolerate some piece of
standard DWARF, that's
> >>>> a missing feature or a bug in the debugger.  Accommodating
that in
> >>>> the compiler is a debugger tuning decision.
> >>>> (example: DW_OP_form_tls_address not understood by GDB)
> >>>> o If some debugger has no use for some piece of standard
DWARF, and
> >>>> it saves space to omit it, that's a debugger tuning
decision.
> >>>> (example: .debug_pubnames/.debug_pubtypes sections)
> >>>> o If a debugger wants things a certain way regardless of
the target,
> >>>> that's probably a debugger tuning decision.
> >>>> o If "system" software on a target (other than
the debugger) wants
> >>>> things a certain way regardless of which debugger
you're using,
> >>>> that's NOT a debugger tuning decision, but a
target-based decision.
> >>>> (example: .debug_aranges section)
> >>>>
> >>>> Let me know if this all seems reasonable, and especially
if you have
> >>>> a good idea where to keep the guidelines.
> >>>> Thanks,
> >>>> --paulr
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> lldb-dev mailing list
> >>>> lldb-dev at cs.uiuc.edu <mailto:lldb-dev at
cs.uiuc.edu>
> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
<http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev>
> >>
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150505/dbdc64fb/attachment.html>

On Tue, May 5, 2015 at 8:16 PM, Adrian Prantl <aprantl at apple.com>
wrote:
>
> On May 5, 2015, at 8:12 PM, David Blaikie <dblaikie at gmail.com>
wrote:
>
>
>
> On Tue, May 5, 2015 at 4:04 PM, Adrian Prantl <aprantl at apple.com>
wrote:
>
>>
>> > On May 1, 2015, at 2:18 PM, Greg Clayton <gclayton at
apple.com> wrote:
>> >
>> >
>> >> On May 1, 2015, at 2:00 PM, Robinson, Paul <
>> Paul_Robinson at playstation.sony.com> wrote:
>> >>
>> >>> A few more things that vote for debugger tuning:
>> >>>
>> >>> - LLDB doesn't like to have DWARF that has a class A
that inherits
>> from
>> >>> class B, but only a forward declaration of class B is
provided.
>> >>
>> >> Hmm do we emit that kind of thing today?  In a naïve test,
I'm seeing
>> >> the full description of class B.
>> >
>> > by default for darwin, it doesn't do this. For others you must
specify
>> -fno-limit-debug-info or some flag like that.
>>
>> I think the option is -f(no-)standalone-debug-info
>
>
> -fno-limit-debug-info == -fstandalone-debug
> (limit-debug-info was the old name & we had a long discussion and
decided
> standalone-debug more aptly described what it should mean/how it should
> generalize)
>
>
> And if my memory serves correctly, what adds to the confusion is that
> -flimit-debug-info used to do more than just this particular optimization,
> but we decided that most of the other optimizations weren’t really helpful,
> so they were removed.
>
Not quite - I refactored the existing optimizations once I figured out what
they did & how it generalized, they are still controlled by the same (both)
flags. There are 3 main optimizations:

1) requires complete type (if a type is referenced, use a declaration
unless the type is required to be complete (eg: it was dereferenced
somewhere, etc))
2) vtable (if a type is dynamic, only emit its definition where the vtable
is emitted)
3) explicit template instantiation (if a type has an explicit template
instantiation declaration, only emit the definition where the explicit
template instantiation definition is)

I really should write a blog post about all this. Seems to create endless
confusion. (so far as I know, GCC only does (2), perhaps it does some other
things that we don't do, but I haven't seen it)

>
>
>
>> which only emits full definitions of classes in the object file that
>> holds and object’s vtable.
>>
>> -- adrian
>> >
>> >>> - LLDB wants the .apple_XXX accelerator tables, GDB wants
>> >>> .debug_pubnames/.debug_pubtypes
>> >>
>> >> Agreed.
>> >>
>> >>> So it would be great to have a "-debugger" flag
that could be
>> specified
>> >>>
>> >>> -debugger=lldb
>> >>> -debugger=gdb
>> >>>
>> >>> Not sure on the option name, but I do like the idea.
>> >>
>> >> We'll bikeshed the name later but yes, that's the
plan.
>> >> Thanks,
>> >> --paulr
>> >>
>> >>>
>> >>> Greg
>> >>>
>> >>>> On May 1, 2015, at 1:06 PM, Robinson, Paul
>> >>> <Paul_Robinson at playstation.sony.com> wrote:
>> >>>>
>> >>>> This is basically a reboot of the previous thread
titled
>> >>>> About the "debugger target"
>> >>>> except that "target" was really too strong a
term for what I had
>> >>> intended
>> >>>> to use this feature for.  "Debugger tuning"
is more like it.  You
>> don't
>> >>>> need to have read the previous thread, I'll recap
here.
>> >>>>
>> >>>> Fundamentally, Clang/LLVM uses DWARF as the
specification for the
>> >>> _format_
>> >>>> of information provided by the compiler to a variety
of "consumers,"
>> >>> which
>> >>>> primarily means debuggers (but not exclusively).  [For
a long time it
>> >>> was
>> >>>> the only format supported by LLVM. Lately, Microsoft
debug info has
>> >>> started
>> >>>> appearing, but being a less widely used format, the
issues that DWARF
>> >>> runs
>> >>>> into aren't a concern for that format.  So
"debugger tuning" is
>> unlikely
>> >>>> to be an issue for Microsoft debug info.]
>> >>>>
>> >>>> DWARF is a permissive standard, meaning that it does
not rigidly
>> require
>> >>>> that source-language construct X must be described
using the DWARF
>> >>>> construct Y.  Instead, DWARF says something more like,
"If you have a
>> >>>> source construct that means something like X,
here's a mechanism Y
>> that
>> >>>> you could use to describe it."  While this gives
compilers a lot of
>> nice
>> >>>> flexibility, it does mean that there's a lot of
wiggle room for how a
>> >>>> compiler describes something and in how a debugger
interprets that
>> >>>> description.  Compilers and debuggers therefore need
to do a bit of
>> >>>> negotiation in determining how the debug-info
"contract" will work,
>> when
>> >>>> it comes to nitty-gritty details.  DWARF itself (the
standard, as
>> well
>> >>>> as the committee that owns the standard) refuses to
get involved in
>> this
>> >>>> negotiation, referring to all that as "quality of
implementation
>> >>> issues."
>> >>>>
>> >>>> It is readily apparent that different debuggers have
different ideas
>> >>>> about certain DWARF features, for example whether they
are useful or
>> >>>> irrelevant, or whether a certain source construct
should be described
>> >>>> this way or that way.  As these generally fall into
the QOI realm,
>> the
>> >>>> DWARF spec itself is no help, and it comes down to a
matter of
>> opinion
>> >>>> about whether "the debugger should just know
this" or "the compiler
>> >>>> really ought to just emit it that way."
>> >>>>
>> >>>> Clang/LLVM is in the position of being a compiler that
wants to
>> support
>> >>>> several different debuggers, all of which have
slightly different
>> ideas
>> >>>> about what they want from the DWARF info for a
program.  Our first
>> line
>> >>>> of defense of course is the DWARF standard itself, but
as we've seen,
>> >>>> that is not a universally definitive reference.
>> >>>>
>> >>>> LLVM already emits DWARF slightly differently for
different
>> *targets*;
>> >>>> primarily Darwin, in a few cases PS4.  But in at least
some cases,
>> the
>> >>>> target is just a (somewhat unreliable) proxy for which
*debugger* the
>> >>>> compiler expects to be consuming the DWARF.  The most
instructive
>> case
>> >>>> is the exact DWARF expression used to describe the
location of a
>> thread-
>> >>>> local variable.  DWARF v3 defined an operator to find
the base
>> address
>> >>>> of the thread-local storage area; however, GDB has
never learned to
>> >>>> recognize it.  Therefore, for targets where we
"know" GDB isn't used,
>> >>>> we can emit the standard operator; for targets where
GDB *might* be
>> >>>> used, we need to emit the equivalent (non-standard)
GNU operator.
>> >>>>
>> >>>> It would be semantically more meaningful to base
decisions like this
>> on
>> >>>> whether we expected the debugger to be X or Y or Z. 
Therefore I've
>> >>>> proposed (http://reviews.llvm.org/D8506) a
"debugger tuning" option
>> that
>> >>>> will make the reasoning behind these choices more
obvious, and
>> >>> ultimately
>> >>>> give users a way to control the tuning themselves,
when the
>> platform's
>> >>>> default isn't what they want. (I'll have a
follow-up patch exposing
>> the
>> >>>> tuning option to the Clang driver.)
>> >>>>
>> >>>> So, what kinds of things should be based on the
debugger tuning
>> option?
>> >>>> Are there still things that should be based on the
target platform?
>> >>>> Simplest to consider these questions together, because
it is often
>> clear
>> >>>> which criterion is important if you consider (a) the
same debugger
>> run
>> >>>> on different targets, versus (b) different debuggers
running on the
>> same
>> >>>> target.  Basically, if the same debugger on different
targets wants
>> to
>> >>>> have something a certain way, that's probably a
debugger-tuning
>> thing.
>> >>>> And if different debuggers on the same target
doesn't mean you should
>> >>>> change how the DWARF looks, that's likely a
platform-specific thing.
>> >>>>
>> >>>> The most obvious example of a debugger-tuning
consideration is the
>> TLS
>> >>>> operator mentioned above. That's something that
GDB insists on
>> having.
>> >>>> (It turns out that the standard operator was defined
in DWARF 3, so
>> we
>> >>>> also have to emit the GNU operator if we're
producing DWARF 2.
>> Tuning
>> >>>> considerations don't trump what the standard
says.)
>> >>>>
>> >>>> Another example would be .debug_pubnames and
.debug_pubtypes
>> sections.
>> >>>> Currently these default to omitted for Darwin and PS4,
but included
>> >>>> everywhere else. My initial patch for
"tuning" changes the PS4
>> platform
>> >>>> criterion to the SCE debugger predicate; quite likely
the "not
>> Darwin"
>> >>>> criterion ought to be "not LLDB" or in other
words "on for GDB only."
>> >>>> And having the code actually reflect the correct
semantic purpose
>> seems
>> >>>> like an overall goodness.
>> >>>>
>> >>>> An example of a target-dependent feature might be the
.debug_aranges
>> >>>> section. As it happens, we don't emit this section
by default,
>> because
>> >>>> apparently no debugger finds it useful, although
there's a
>> command-line
>> >>>> option (-gdwarf-aranges) for it.  But, for PS4 we do
want to emit it,
>> >>>> because we have non-debugger tools that find it
useful.  We haven't
>> yet
>> >>>> done the work to make that change on llvm.org, but
it's on the list.
>> >>>> I would conditionalize this on the target, not the
debugger, because
>> >>>> the debugger is not why we want to generate the
section.
>> >>>>
>> >>>> Okay, so I've been pretty long-winded about all
this, can I possibly
>> >>>> codify it all into a reasonably succinct set of
guidelines?  (which
>> >>>> ought to be committed to the repo somewhere, although
whether it's as
>> >>>> a lump of text in a docs webpage or a lump of
commentary in some
>> source
>> >>>> file is not clear; opinions welcome.)
>> >>>>
>> >>>> o Emit standard DWARF if possible.
>> >>>> o Omitting standard DWARF features that nobody uses is
fine.
>> >>>> (example: DW_AT_sibling)
>> >>>> o Extensions are okay, but think about the
circumstances where they
>> >>>> would be useful (versus just wasting space).  These
are probably a
>> >>>> debugger tuning decision, but might be a target-based
decision.
>> >>>> (example: DW_AT_APPLE_* attributes)
>> >>>> o If some debugger can't tolerate some piece of
standard DWARF,
>> that's
>> >>>> a missing feature or a bug in the debugger. 
Accommodating that in
>> >>>> the compiler is a debugger tuning decision.
>> >>>> (example: DW_OP_form_tls_address not understood by
GDB)
>> >>>> o If some debugger has no use for some piece of
standard DWARF, and
>> >>>> it saves space to omit it, that's a debugger
tuning decision.
>> >>>> (example: .debug_pubnames/.debug_pubtypes sections)
>> >>>> o If a debugger wants things a certain way regardless
of the target,
>> >>>> that's probably a debugger tuning decision.
>> >>>> o If "system" software on a target (other
than the debugger) wants
>> >>>> things a certain way regardless of which debugger
you're using,
>> >>>> that's NOT a debugger tuning decision, but a
target-based decision.
>> >>>> (example: .debug_aranges section)
>> >>>>
>> >>>> Let me know if this all seems reasonable, and
especially if you have
>> >>>> a good idea where to keep the guidelines.
>> >>>> Thanks,
>> >>>> --paulr
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> lldb-dev mailing list
>> >>>> lldb-dev at cs.uiuc.edu
>> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>> >>
>> >
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150505/2063780d/attachment.html>

I just skimmed through the thread again, and I *think* all the main questions
have been answered…
It feels like the consensus is "reluctant agreement," with the
specific design points being:

-        a "debugger tuning" option would have some sort of
target-based default

-        the "debugger tuning" option would unpack into defaults for
individual feature flags

-        emitting actual DWARF would test the feature flags not the tuning
option

-        any command-line options for feature flags would override the
tuning-based defaults

If I missed anything, let me know, otherwise I'll go back go pinging the
patch.
Thanks,
--paulr

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of David Blaikie
Sent: Tuesday, May 05, 2015 8:21 PM
To: Adrian Prantl
Cc: lldb-dev at cs.uiuc.edu; Greg Clayton; cfe-dev at cs.uiuc.edu Developers
(cfe-dev at cs.uiuc.edu); LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
Subject: Re: [LLVMdev] [cfe-dev] [lldb-dev] What does "debugger
tuning" mean?



On Tue, May 5, 2015 at 8:16 PM, Adrian Prantl <aprantl at
apple.com<mailto:aprantl at apple.com>> wrote:

On May 5, 2015, at 8:12 PM, David Blaikie <dblaikie at
gmail.com<mailto:dblaikie at gmail.com>> wrote:



On Tue, May 5, 2015 at 4:04 PM, Adrian Prantl <aprantl at
apple.com<mailto:aprantl at apple.com>> wrote:
> On May 1, 2015, at 2:18 PM, Greg Clayton <gclayton at
apple.com<mailto:gclayton at apple.com>> wrote:
>
>
>> On May 1, 2015, at 2:00 PM, Robinson, Paul <Paul_Robinson at
playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>>
wrote:
>>
>>> A few more things that vote for debugger tuning:
>>>
>>> - LLDB doesn't like to have DWARF that has a class A that
inherits from
>>> class B, but only a forward declaration of class B is provided.
>>
>> Hmm do we emit that kind of thing today?  In a naïve test, I'm
seeing
>> the full description of class B.
>
> by default for darwin, it doesn't do this. For others you must specify
-fno-limit-debug-info or some flag like that.
I think the option is -f(no-)standalone-debug-info

-fno-limit-debug-info == -fstandalone-debug
(limit-debug-info was the old name & we had a long discussion and decided
standalone-debug more aptly described what it should mean/how it should
generalize)

And if my memory serves correctly, what adds to the confusion is that
-flimit-debug-info used to do more than just this particular optimization, but
we decided that most of the other optimizations weren’t really helpful, so they
were removed.

Not quite - I refactored the existing optimizations once I figured out what they
did & how it generalized, they are still controlled by the same (both)
flags. There are 3 main optimizations:

1) requires complete type (if a type is referenced, use a declaration unless the
type is required to be complete (eg: it was dereferenced somewhere, etc))
2) vtable (if a type is dynamic, only emit its definition where the vtable is
emitted)
3) explicit template instantiation (if a type has an explicit template
instantiation declaration, only emit the definition where the explicit template
instantiation definition is)

I really should write a blog post about all this. Seems to create endless
confusion. (so far as I know, GCC only does (2), perhaps it does some other
things that we don't do, but I haven't seen it)




which only emits full definitions of classes in the object file that holds and
object’s vtable.

-- adrian
>
>>> - LLDB wants the .apple_XXX accelerator tables, GDB wants
>>> .debug_pubnames/.debug_pubtypes
>>
>> Agreed.
>>
>>> So it would be great to have a "-debugger" flag that
could be specified
>>>
>>> -debugger=lldb
>>> -debugger=gdb
>>>
>>> Not sure on the option name, but I do like the idea.
>>
>> We'll bikeshed the name later but yes, that's the plan.
>> Thanks,
>> --paulr
>>
>>>
>>> Greg
>>>
>>>> On May 1, 2015, at 1:06 PM, Robinson, Paul
>>> <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson
at playstation.sony.com>> wrote:
>>>>
>>>> This is basically a reboot of the previous thread titled
>>>> About the "debugger target"
>>>> except that "target" was really too strong a term for
what I had
>>> intended
>>>> to use this feature for.  "Debugger tuning" is more
like it.  You don't
>>>> need to have read the previous thread, I'll recap here.
>>>>
>>>> Fundamentally, Clang/LLVM uses DWARF as the specification for
the
>>> _format_
>>>> of information provided by the compiler to a variety of
"consumers,"
>>> which
>>>> primarily means debuggers (but not exclusively).  [For a long
time it
>>> was
>>>> the only format supported by LLVM. Lately, Microsoft debug info
has
>>> started
>>>> appearing, but being a less widely used format, the issues that
DWARF
>>> runs
>>>> into aren't a concern for that format.  So "debugger
tuning" is unlikely
>>>> to be an issue for Microsoft debug info.]
>>>>
>>>> DWARF is a permissive standard, meaning that it does not
rigidly require
>>>> that source-language construct X must be described using the
DWARF
>>>> construct Y.  Instead, DWARF says something more like, "If
you have a
>>>> source construct that means something like X, here's a
mechanism Y that
>>>> you could use to describe it."  While this gives compilers
a lot of nice
>>>> flexibility, it does mean that there's a lot of wiggle room
for how a
>>>> compiler describes something and in how a debugger interprets
that
>>>> description.  Compilers and debuggers therefore need to do a
bit of
>>>> negotiation in determining how the debug-info
"contract" will work, when
>>>> it comes to nitty-gritty details.  DWARF itself (the standard,
as well
>>>> as the committee that owns the standard) refuses to get
involved in this
>>>> negotiation, referring to all that as "quality of
implementation
>>> issues."
>>>>
>>>> It is readily apparent that different debuggers have different
ideas
>>>> about certain DWARF features, for example whether they are
useful or
>>>> irrelevant, or whether a certain source construct should be
described
>>>> this way or that way.  As these generally fall into the QOI
realm, the
>>>> DWARF spec itself is no help, and it comes down to a matter of
opinion
>>>> about whether "the debugger should just know this" or
"the compiler
>>>> really ought to just emit it that way."
>>>>
>>>> Clang/LLVM is in the position of being a compiler that wants to
support
>>>> several different debuggers, all of which have slightly
different ideas
>>>> about what they want from the DWARF info for a program.  Our
first line
>>>> of defense of course is the DWARF standard itself, but as
we've seen,
>>>> that is not a universally definitive reference.
>>>>
>>>> LLVM already emits DWARF slightly differently for different
*targets*;
>>>> primarily Darwin, in a few cases PS4.  But in at least some
cases, the
>>>> target is just a (somewhat unreliable) proxy for which
*debugger* the
>>>> compiler expects to be consuming the DWARF.  The most
instructive case
>>>> is the exact DWARF expression used to describe the location of
a thread-
>>>> local variable.  DWARF v3 defined an operator to find the base
address
>>>> of the thread-local storage area; however, GDB has never
learned to
>>>> recognize it.  Therefore, for targets where we "know"
GDB isn't used,
>>>> we can emit the standard operator; for targets where GDB
*might* be
>>>> used, we need to emit the equivalent (non-standard) GNU
operator.
>>>>
>>>> It would be semantically more meaningful to base decisions like
this on
>>>> whether we expected the debugger to be X or Y or Z.  Therefore
I've
>>>> proposed (http://reviews.llvm.org/D8506) a "debugger
tuning" option that
>>>> will make the reasoning behind these choices more obvious, and
>>> ultimately
>>>> give users a way to control the tuning themselves, when the
platform's
>>>> default isn't what they want. (I'll have a follow-up
patch exposing the
>>>> tuning option to the Clang driver.)
>>>>
>>>> So, what kinds of things should be based on the debugger tuning
option?
>>>> Are there still things that should be based on the target
platform?
>>>> Simplest to consider these questions together, because it is
often clear
>>>> which criterion is important if you consider (a) the same
debugger run
>>>> on different targets, versus (b) different debuggers running on
the same
>>>> target.  Basically, if the same debugger on different targets
wants to
>>>> have something a certain way, that's probably a
debugger-tuning thing.
>>>> And if different debuggers on the same target doesn't mean
you should
>>>> change how the DWARF looks, that's likely a
platform-specific thing.
>>>>
>>>> The most obvious example of a debugger-tuning consideration is
the TLS
>>>> operator mentioned above. That's something that GDB insists
on having.
>>>> (It turns out that the standard operator was defined in DWARF
3, so we
>>>> also have to emit the GNU operator if we're producing DWARF
2.  Tuning
>>>> considerations don't trump what the standard says.)
>>>>
>>>> Another example would be .debug_pubnames and .debug_pubtypes
sections.
>>>> Currently these default to omitted for Darwin and PS4, but
included
>>>> everywhere else. My initial patch for "tuning"
changes the PS4 platform
>>>> criterion to the SCE debugger predicate; quite likely the
"not Darwin"
>>>> criterion ought to be "not LLDB" or in other words
"on for GDB only."
>>>> And having the code actually reflect the correct semantic
purpose seems
>>>> like an overall goodness.
>>>>
>>>> An example of a target-dependent feature might be the
.debug_aranges
>>>> section. As it happens, we don't emit this section by
default, because
>>>> apparently no debugger finds it useful, although there's a
command-line
>>>> option (-gdwarf-aranges) for it.  But, for PS4 we do want to
emit it,
>>>> because we have non-debugger tools that find it useful.  We
haven't yet
>>>> done the work to make that change on
llvm.org<http://llvm.org/>, but it's on the list.
>>>> I would conditionalize this on the target, not the debugger,
because
>>>> the debugger is not why we want to generate the section.
>>>>
>>>> Okay, so I've been pretty long-winded about all this, can I
possibly
>>>> codify it all into a reasonably succinct set of guidelines? 
(which
>>>> ought to be committed to the repo somewhere, although whether
it's as
>>>> a lump of text in a docs webpage or a lump of commentary in
some source
>>>> file is not clear; opinions welcome.)
>>>>
>>>> o Emit standard DWARF if possible.
>>>> o Omitting standard DWARF features that nobody uses is fine.
>>>> (example: DW_AT_sibling)
>>>> o Extensions are okay, but think about the circumstances where
they
>>>> would be useful (versus just wasting space).  These are
probably a
>>>> debugger tuning decision, but might be a target-based decision.
>>>> (example: DW_AT_APPLE_* attributes)
>>>> o If some debugger can't tolerate some piece of standard
DWARF, that's
>>>> a missing feature or a bug in the debugger.  Accommodating that
in
>>>> the compiler is a debugger tuning decision.
>>>> (example: DW_OP_form_tls_address not understood by GDB)
>>>> o If some debugger has no use for some piece of standard DWARF,
and
>>>> it saves space to omit it, that's a debugger tuning
decision.
>>>> (example: .debug_pubnames/.debug_pubtypes sections)
>>>> o If a debugger wants things a certain way regardless of the
target,
>>>> that's probably a debugger tuning decision.
>>>> o If "system" software on a target (other than the
debugger) wants
>>>> things a certain way regardless of which debugger you're
using,
>>>> that's NOT a debugger tuning decision, but a target-based
decision.
>>>> (example: .debug_aranges section)
>>>>
>>>> Let me know if this all seems reasonable, and especially if you
have
>>>> a good idea where to keep the guidelines.
>>>> Thanks,
>>>> --paulr
>>>>
>>>>
>>>> _______________________________________________
>>>> lldb-dev mailing list
>>>> lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu>
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu<http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150506/bd749d24/attachment.html>