llvm dev - Feb 2020 - Enabling debug entry value production by default

Hi all,

I think we've reached a state where we're ready to enable debug entry
value production by default for the x86_64, ARM, and AArch64 targets. For
context, this is a debug info feature that allows debuggers to recover the value
of unmodified optimized-out parameters by 'going up' a stack frame and
interpreting spilled values, constants, etc. to work out what was passed to the
callee. There's a nice write-up about the impact of this feature in [3]. A
big thank you to all of contributors who've helped us get here (I've
tried to CC everyone, sincere apologies if I've accidentally left you out).

I believe Djordje and I have shown that there isn't an outsized binary size
or compile time impact of enabling this feature. The aggregate size of DWARF in
a stage2 x86_64 RelWithDebInfo clang build grows by under 0.2%, and we
didn't find a significant compile time impact. We've shared CTMark
results (both compile-time & DWARF section size numbers), as well as a size
analysis of stage2 builds of {llc, clang, lldb} in [1].

Djordje has also shared a nice location statistics comparison chart in [1],
showing increased variable availability with entry values enabled.

For my part, I instrumented lldb's DWARFExpression::Evaluate method to log
instances in which a variable location is unavailable. I then used a script [4]
to single-step through a stage2 RelWithDebInfo+entryvals clang binary as it was
compiling sqlite3.c, printing local variables at each stop. Without entry
values, lldb reported "variable not available" 883,918 times. With
entry values lldb reported "variable not available" 687,899 times (a
22% drop).

Does anyone have concerns about enabling this feature?

thanks,
vedant

[1] [DebugInfo] Enable the debug entry values feature by default
<https://reviews.llvm.org/D73534>
[2] [CallSiteInfo] Fix the assertions regarding updating the CallSiteInfo
<https://reviews.llvm.org/D73700>, [CallSiteInfo] Use the
isCandidateForCallSiteEntry() when update the cs info
<https://reviews.llvm.org/D74122>[3]
https://robert.ocallahan.org/2018/11/comparing-quality-of-debug-information.html
<https://robert.ocallahan.org/2018/11/comparing-quality-of-debug-information.html>
[4] https://gist.github.com/vedantk/7602b20a9e1d44c42d32dcca36591cc0
<https://gist.github.com/vedantk/7602b20a9e1d44c42d32dcca36591cc0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200207/79f75eab/attachment.html>

(trying to add back folks dropped by Mail.app...)

+ David Blaikie, David Stenberg, Adrian, Jeremy, and Fred
> On Feb 7, 2020, at 12:04 PM, Vedant Kumar via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi all,
> 
> I think we've reached a state where we're ready to enable debug
entry value production by default for the x86_64, ARM, and AArch64 targets. For
context, this is a debug info feature that allows debuggers to recover the value
of unmodified optimized-out parameters by 'going up' a stack frame and
interpreting spilled values, constants, etc. to work out what was passed to the
callee. There's a nice write-up about the impact of this feature in [3]. A
big thank you to all of contributors who've helped us get here (I've
tried to CC everyone, sincere apologies if I've accidentally left you out).
> 
> I believe Djordje and I have shown that there isn't an outsized binary
size or compile time impact of enabling this feature. The aggregate size of
DWARF in a stage2 x86_64 RelWithDebInfo clang build grows by under 0.2%, and we
didn't find a significant compile time impact. We've shared CTMark
results (both compile-time & DWARF section size numbers), as well as a size
analysis of stage2 builds of {llc, clang, lldb} in [1].
> 
> Djordje has also shared a nice location statistics comparison chart in [1],
showing increased variable availability with entry values enabled.
> 
> For my part, I instrumented lldb's DWARFExpression::Evaluate method to
log instances in which a variable location is unavailable. I then used a script
[4] to single-step through a stage2 RelWithDebInfo+entryvals clang binary as it
was compiling sqlite3.c, printing local variables at each stop. Without entry
values, lldb reported "variable not available" 883,918 times. With
entry values lldb reported "variable not available" 687,899 times (a
22% drop).
> 
> Does anyone have concerns about enabling this feature?
> 
> thanks,
> vedant
> 
> [1] [DebugInfo] Enable the debug entry values feature by default
<https://reviews.llvm.org/D73534>
> [2] [CallSiteInfo] Fix the assertions regarding updating the CallSiteInfo
<https://reviews.llvm.org/D73700>, [CallSiteInfo] Use the
isCandidateForCallSiteEntry() when update the cs info
<https://reviews.llvm.org/D74122>[3]
https://robert.ocallahan.org/2018/11/comparing-quality-of-debug-information.html
<https://robert.ocallahan.org/2018/11/comparing-quality-of-debug-information.html>
> [4] https://gist.github.com/vedantk/7602b20a9e1d44c42d32dcca36591cc0
<https://gist.github.com/vedantk/7602b20a9e1d44c42d32dcca36591cc0>_______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200207/5069661d/attachment.html>

This would only be enabled when optimizations are enabled, correct?

For GDB and LLDB debug info tuning mode, this sounds good to me. I don't
know if, e.g., the Sony debugger supports entry values. Out of curiosity, does
anyone know if GCC enable entry values by default?

-- adrian
> On Feb 7, 2020, at 12:09 PM, Vedant Kumar <vedant_kumar at apple.com>
wrote:
> 
> (trying to add back folks dropped by Mail.app...)
> 
> + David Blaikie, David Stenberg, Adrian, Jeremy, and Fred
> 
>> On Feb 7, 2020, at 12:04 PM, Vedant Kumar via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> Hi all,
>> 
>> I think we've reached a state where we're ready to enable debug
entry value production by default for the x86_64, ARM, and AArch64 targets. For
context, this is a debug info feature that allows debuggers to recover the value
of unmodified optimized-out parameters by 'going up' a stack frame and
interpreting spilled values, constants, etc. to work out what was passed to the
callee. There's a nice write-up about the impact of this feature in [3]. A
big thank you to all of contributors who've helped us get here (I've
tried to CC everyone, sincere apologies if I've accidentally left you out).
>> 
>> I believe Djordje and I have shown that there isn't an outsized
binary size or compile time impact of enabling this feature. The aggregate size
of DWARF in a stage2 x86_64 RelWithDebInfo clang build grows by under 0.2%, and
we didn't find a significant compile time impact. We've shared CTMark
results (both compile-time & DWARF section size numbers), as well as a size
analysis of stage2 builds of {llc, clang, lldb} in [1].
>> 
>> Djordje has also shared a nice location statistics comparison chart in
[1], showing increased variable availability with entry values enabled.
>> 
>> For my part, I instrumented lldb's DWARFExpression::Evaluate method
to log instances in which a variable location is unavailable. I then used a
script [4] to single-step through a stage2 RelWithDebInfo+entryvals clang binary
as it was compiling sqlite3.c, printing local variables at each stop. Without
entry values, lldb reported "variable not available" 883,918 times.
With entry values lldb reported "variable not available" 687,899 times
(a 22% drop).
>> 
>> Does anyone have concerns about enabling this feature?
>> 
>> thanks,
>> vedant
>> 
>> [1] [DebugInfo] Enable the debug entry values feature by default
<https://reviews.llvm.org/D73534>
>> [2] [CallSiteInfo] Fix the assertions regarding updating the
CallSiteInfo <https://reviews.llvm.org/D73700>, [CallSiteInfo] Use the
isCandidateForCallSiteEntry() when update the cs info
<https://reviews.llvm.org/D74122>[3]
https://robert.ocallahan.org/2018/11/comparing-quality-of-debug-information.html
<https://robert.ocallahan.org/2018/11/comparing-quality-of-debug-information.html>
>> [4] https://gist.github.com/vedantk/7602b20a9e1d44c42d32dcca36591cc0
<https://gist.github.com/vedantk/7602b20a9e1d44c42d32dcca36591cc0>_______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200207/500f1529/attachment.html>

For that sort of small growth, if it doesn't add more relocations (I think
the call sites need them (but they're already emitted/that's not what
we're
discussing enabling here), but call value descriptions don't), sounds good
to me :)

On Fri, Feb 7, 2020 at 12:04 PM Vedant Kumar <vedant_kumar at apple.com>
wrote:
> Hi all,
>
> I think we've reached a state where we're ready to enable debug
entry
> value production by default for the x86_64, ARM, and AArch64 targets. For
> context, this is a debug info feature that allows debuggers to recover the
> value of unmodified optimized-out parameters by 'going up' a stack
frame
> and interpreting spilled values, constants, etc. to work out what was
> passed to the callee. There's a nice write-up about the impact of this
> feature in [3]. A big thank you to all of contributors who've helped us
get
> here (I've tried to CC everyone, sincere apologies if I've
accidentally
> left you out).
>
> I believe Djordje and I have shown that there isn't an outsized binary
> size or compile time impact of enabling this feature. The aggregate size of
> DWARF in a stage2 x86_64 RelWithDebInfo clang build grows by under 0.2%,
> and we didn't find a significant compile time impact. We've shared
CTMark
> results (both compile-time & DWARF section size numbers), as well as a
size
> analysis of stage2 builds of {llc, clang, lldb} in [1].
>
> Djordje has also shared a nice location statistics comparison chart in
> [1], showing increased variable availability with entry values enabled.
>
> For my part, I instrumented lldb's DWARFExpression::Evaluate method to
log
> instances in which a variable location is unavailable. I then used a script
> [4] to single-step through a stage2 RelWithDebInfo+entryvals clang binary
> as it was compiling sqlite3.c, printing local variables at each stop.
> Without entry values, lldb reported "variable not available"
883,918 times.
> With entry values lldb reported "variable not available" 687,899
times (a
> 22% drop).
>
> Does anyone have concerns about enabling this feature?
>
> thanks,
> vedant
>
> [1] [DebugInfo] Enable the debug entry values feature by default
> <https://reviews.llvm.org/D73534>
> [2] [CallSiteInfo] Fix the assertions regarding updating the CallSiteInfo
> <https://reviews.llvm.org/D73700>, [CallSiteInfo] Use the
> isCandidateForCallSiteEntry() when update the cs info
> <https://reviews.llvm.org/D74122>
> [3]
>
https://robert.ocallahan.org/2018/11/comparing-quality-of-debug-information.html
> [4] https://gist.github.com/vedantk/7602b20a9e1d44c42d32dcca36591cc0
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200207/e6905ae7/attachment.html>

Yep, TAG_call_site_parameter and its children shouldn't require any extra
relocations. Thanks!

vedant
> On Feb 7, 2020, at 2:01 PM, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> For that sort of small growth, if it doesn't add more relocations (I
think the call sites need them (but they're already emitted/that's not
what we're discussing enabling here), but call value descriptions
don't), sounds good to me :)
> 
> On Fri, Feb 7, 2020 at 12:04 PM Vedant Kumar <vedant_kumar at apple.com
<mailto:vedant_kumar at apple.com>> wrote:
> Hi all,
> 
> I think we've reached a state where we're ready to enable debug
entry value production by default for the x86_64, ARM, and AArch64 targets. For
context, this is a debug info feature that allows debuggers to recover the value
of unmodified optimized-out parameters by 'going up' a stack frame and
interpreting spilled values, constants, etc. to work out what was passed to the
callee. There's a nice write-up about the impact of this feature in [3]. A
big thank you to all of contributors who've helped us get here (I've
tried to CC everyone, sincere apologies if I've accidentally left you out).
> 
> I believe Djordje and I have shown that there isn't an outsized binary
size or compile time impact of enabling this feature. The aggregate size of
DWARF in a stage2 x86_64 RelWithDebInfo clang build grows by under 0.2%, and we
didn't find a significant compile time impact. We've shared CTMark
results (both compile-time & DWARF section size numbers), as well as a size
analysis of stage2 builds of {llc, clang, lldb} in [1].
> 
> Djordje has also shared a nice location statistics comparison chart in [1],
showing increased variable availability with entry values enabled.
> 
> For my part, I instrumented lldb's DWARFExpression::Evaluate method to
log instances in which a variable location is unavailable. I then used a script
[4] to single-step through a stage2 RelWithDebInfo+entryvals clang binary as it
was compiling sqlite3.c, printing local variables at each stop. Without entry
values, lldb reported "variable not available" 883,918 times. With
entry values lldb reported "variable not available" 687,899 times (a
22% drop).
> 
> Does anyone have concerns about enabling this feature?
> 
> thanks,
> vedant
> 
> [1] [DebugInfo] Enable the debug entry values feature by default
<https://reviews.llvm.org/D73534>
> [2] [CallSiteInfo] Fix the assertions regarding updating the CallSiteInfo
<https://reviews.llvm.org/D73700>, [CallSiteInfo] Use the
isCandidateForCallSiteEntry() when update the cs info
<https://reviews.llvm.org/D74122>[3]
https://robert.ocallahan.org/2018/11/comparing-quality-of-debug-information.html
<https://robert.ocallahan.org/2018/11/comparing-quality-of-debug-information.html>
> [4] https://gist.github.com/vedantk/7602b20a9e1d44c42d32dcca36591cc0
<https://gist.github.com/vedantk/7602b20a9e1d44c42d32dcca36591cc0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200207/1ab64869/attachment.html>