Re: [LVU] use asm .loc and get gas to compute views on the side

[Jakub Jelinek]

On Sat, Feb 10, 2018 at 09:26:47AM -0700, Jeff Law wrote:
> > I think it makes sense to disable them by default if gas doesn't support
> > them with that ability to override the auto detection by a configure
> > switch (get the GCC generated ones).  The patch looks too heavy for this
> > stage and as you say we lack support on the consumer side anyways.  We
> > can revisit this patch for GCC 9 or simply document the recommendation
> > of using gas 2.30 or newer.

> Seems reasonable to me as well.

We should have a switch to force gcc generated .debug_line in any case,
similarly how we have -fno-dwarf2-cfi-asm.
E.g. only the gcc generated .debug_line can do DWARF5 .debug_line right now,
gas generated one can't.

Jakub

Re: [LVU] use asm .loc and get gas to compute views on the side

[Jeff Law]

On 02/10/2018 06:34 AM, Richard Biener wrote:
> On February 10, 2018 1:53:41 PM GMT+01:00, Alexandre Oliva 
>  wrote:
>> I was shocked when you, richi, reported huge debug info growth after
>> the
>> LVU and IEPM patches went in.  At first, I suspected IEPM, due to
>> possibly keeping more lexical blocks around, but my investigation
>> showed
>> a lot of the growth was actually due to switching from asm-generated
>> line number sections to gcc-generated ones, which we do when locviews
>> are requested but the assembler has no support for view assignments in
>> .loc directives.
>>
>> It then occurred to me that we could compute view numbers on the side,
>> and I jumped at it before recalling there were complications I was
>> already familiar with, namely that .loc directives (without views)
>> don't
>> necessarily bind to '.': they bind to the next instruction, which might
>> even be in a different section.  This makes for some complications,
>> verbosely described in comments in dwarf2out.c.  I'm reasonably happy
>> with the result, that passed visual inspection on some reasonably
>> tricky
>> cases, but there's unfortunately no way I can think of to test
>> mechanically that the views we get from gas-generated line number
>> programs correspond to the views we compute from the labels introduced
>> by the patch.  Although we might get view numbers wrong in some unknown
>> cases, that we'll only notice for real once we have loc view support in
>> debuggers, since actual insns are sync (reset) points for views, odds
>> are they will be in sync at most points of interest.
>>
>> So, do you think the far more compact debug_line sections are worth the
>> risk of some out-of-sync view counts, for those who already use gas,
>> just not 2.30?  Or should we instead default to disabling views when
>> the
>> assembler doesn't have native support for them, as you had suggested?
>>
>> (I haven't looked yet into the other debug_info growth, most certainly
>> caused by IEPM-preserved lexical blocks; that's next up, but I'll need
>> another sleep cycle first, I'm afraid)
>>
>> WDYT?
> 
> I think it makes sense to disable them by default if gas doesn't support them 
> with that ability to override the auto detection by a configure switch (get 
> the GCC generated ones). The patch looks too heavy for this stage and as you 
> say we lack support on the consumer side anyways. We can revisit this patch 
> for GCC 9 or simply document the recommendation of using gas 2.30 or newer. 
Seems reasonable to me as well.
jeff

Re: [LVU] use asm .loc and get gas to compute views on the side

[Richard Biener]

On February 10, 2018 1:53:41 PM GMT+01:00, Alexandre Oliva  
wrote:
>I was shocked when you, richi, reported huge debug info growth after
>the
>LVU and IEPM patches went in.  At first, I suspected IEPM, due to
>possibly keeping more lexical blocks around, but my investigation
>showed
>a lot of the growth was actually due to switching from asm-generated
>line number sections to gcc-generated ones, which we do when locviews
>are requested but the assembler has no support for view assignments in
>.loc directives.
>
>It then occurred to me that we could compute view numbers on the side,
>and I jumped at it before recalling there were complications I was
>already familiar with, namely that .loc directives (without views)
>don't
>necessarily bind to '.': they bind to the next instruction, which might
>even be in a different section.  This makes for some complications,
>verbosely described in comments in dwarf2out.c.  I'm reasonably happy
>with the result, that passed visual inspection on some reasonably
>tricky
>cases, but there's unfortunately no way I can think of to test
>mechanically that the views we get from gas-generated line number
>programs correspond to the views we compute from the labels introduced
>by the patch.  Although we might get view numbers wrong in some unknown
>cases, that we'll only notice for real once we have loc view support in
>debuggers, since actual insns are sync (reset) points for views, odds
>are they will be in sync at most points of interest.
>
>So, do you think the far more compact debug_line sections are worth the
>risk of some out-of-sync view counts, for those who already use gas,
>just not 2.30?  Or should we instead default to disabling views when
>the
>assembler doesn't have native support for them, as you had suggested?
>
>(I haven't looked yet into the other debug_info growth, most certainly
>caused by IEPM-preserved lexical blocks; that's next up, but I'll need
>another sleep cycle first, I'm afraid)
>
>WDYT?

I think it makes sense to disable them by default if gas doesn't support them 
with that ability to override the auto detection by a configure switch (get the 
GCC generated ones). The patch looks too heavy for this stage and as you say we 
lack support on the consumer side anyways. We can revisit this patch for GCC 9 
or simply document the recommendation of using gas 2.30 or newer. 

Richard. 
>
>
>introduce asm-fallback view computation mode
>
>
>---
> gcc/config.in|6 +
> gcc/configure|   55 ++-
> gcc/configure.ac |   23 
>gcc/dwarf2out.c  |  282
>++
> gcc/final.c  |   15 +++
> 5 files changed, 360 insertions(+), 21 deletions(-)
>
>diff --git a/gcc/config.in b/gcc/config.in
>index 5bccb408016b..f31f79763fb4 100644
>--- a/gcc/config.in
>+++ b/gcc/config.in
>@@ -315,6 +315,12 @@
> #endif
> 
> 
>+/* Define if your assembler supports computing views from labels. */
>+#ifndef USED_FOR_TARGET
>+#undef HAVE_AS_COMPUTED_DEBUG_VIEW
>+#endif
>+
>+
> /* Define if your assembler supports the DCI/ICI instructions. */
> #ifndef USED_FOR_TARGET
> #undef HAVE_AS_DCI
>diff --git a/gcc/configure b/gcc/configure
>index b12628725b67..758737daf296 100755
>--- a/gcc/configure
>+++ b/gcc/configure
>@@ -27843,7 +27843,7 @@ else
>   gcc_cv_as_dwarf2_debug_view=no
> if test $in_tree_gas = yes; then
> if test $in_tree_gas_is_elf = yes \
>-  && test $gcc_cv_gas_vers -ge `expr \( \( 2 \* 1000 \) + 27 \) \*
>1000 + 0`
>+  && test $gcc_cv_gas_vers -ge `expr \( \( 2 \* 1000 \) + 30 \) \*
>1000 + 0`
>   then gcc_cv_as_dwarf2_debug_view=yes
> fi
>   elif test x$gcc_cv_as != x; then
>@@ -27870,6 +27870,59 @@ if test $gcc_cv_as_dwarf2_debug_view = yes;
>then
> $as_echo "#define HAVE_AS_DWARF2_DEBUG_VIEW 1" >>confdefs.h
> 
> fi
>+
>+
>+  conftest_s="\
>+  .data
>+  .LVUL0:
>+  .set .LVU0, 0
>+  .LVUL1:
>+  .set .LVU1, (.LVU0 + 1) * !(.LVUL1 > .LVUL0)
>+  .space 1
>+  .LVUL2:
>+  .set .LVU2, (.LVU1 + 1) * !(.LVUL2 > .LVUL1)
>+
>+  .uleb128 .LVU0
>+  .uleb128 .LVU1
>+  .uleb128 .LVU2
>+"
>+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for
>dwarf2 debug_view support fallback" >&5
>+$as_echo_n "checking assembler for dwarf2 debug_view support
>fallback... " >&6; }
>+if test "${gcc_cv_as_dwarf2_debug_view_fallback+set}" = set; then :
>+  $as_echo_n "(cached) " >&6
>+else
>+  gcc_cv_as_dwarf2_debug_view_fallback=no
>+if test $in_tree_gas = yes; then
>+if test $in_tree_gas_is_elf = yes \
>+  && test $gcc_cv_gas_vers -ge `expr \( \( 2 \* 1000 \) + 30 \) \*
>1000 + 0`
>+  then gcc_cv_as_dwarf2_debug_view_fallback=yes
>+fi
>+  elif test x$gcc_cv_as != x; then
>+$as_echo "$conftest_s" > conftest.s
>+if { ac_try='$gcc_cv_as $gcc_cv_as_flags  -o conftest.o conftest.s
>>&5'
>+  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
>+  (eval $ac_try) 2>&5
>+  ac_status=$?
>+  $as_echo