[Bug debug/55608] New: [4.6/4.7/4.8 Regression] Debug info quality regressions with file scope vars

[Bug debug/55608] New: [4.6/4.7/4.8 Regression] Debug info quality regressions with file scope vars

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55608

             Bug #: 55608
           Summary: [4.6/4.7/4.8 Regression] Debug info quality
                    regressions with file scope vars
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: jakub@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org


static const char *a = "opq";
static const char b[8] = "rstuv";

int
main ()
{
  const char *p = "abcd";
  const char *q = "efgh";
  const char r[] = "ijk\0lmn";
  const char *s = r;
  return 0;
}

at -g -O2, gdb ./test; b main; p a; p b
shows
(gdb) p a
$1 = 0x400560 "opq"
(gdb) p b
$2 = "rstuv\000\000"
in e.g. GCC 3.2 or 3.3, but later on it is <optimized out>.  This is related to
PR55395, without reverting or adjusting part of that all the info is gone.
I have a patch which so far makes p b work (if a non-DECL_EXTERNAL variable is
optimized away and had an initializer, it means nothing is actually changing it
and so we can add DW_AT_const_value attribute), plans how to do some other vars
in this testcase.

[Bug debug/55608] [4.6/4.7/4.8 Regression] Debug info quality regressions with file scope vars

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55608

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-12-06
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2012-12-06 09:05:12 UTC ---
One might argue that not including unused static(!) const vars that might come
from headers in all TUs is a good thing - for debug info size, for example.
Definitely debug info is already way too large - and we don't include
optimized out functions either (so you cannot do inferior calls to them
from the debugging session).  I don't really see the difference between
functions and variables here.  Functions even don't print <optimized out>
but just

(gdb) start
Temporary breakpoint 1 at 0x4004c4: file t.c, line 5.
Starting program: /tmp/t 

Temporary breakpoint 1, main () at t.c:5
5       }
(gdb) p foo
No symbol "foo" in current context.
(gdb) p foo ()
No symbol "foo" in current context.


testcase:

static int foo (void) { return 1; }
int main()
{
  return 0;
}


at least can we emit this info on unused stuff with -g3 only?

[Bug debug/55608] [4.6/4.7/4.8 Regression] Debug info quality regressions with file scope vars

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55608

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-12-06 09:12:24 UTC ---
I think there is a duplicated bug of this one where we closed it as behaviors
correctly but I don't know the number right now.

[Bug debug/55608] [4.6/4.7/4.8 Regression] Debug info quality regressions with file scope vars

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55608

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-06 09:15:24 UTC ---
-g3 isn't the right switch for that, that is historically about enabling
.debug_macinfo/.debug_macro.  We have various -feliminate-unused-debug*
options.
But generally, we try to emit (for -fvar-tracking-assignments) debug info even
for unused automatic vars, I don't see why file scope vars should be any
different.  Perhaps we can add some --param how large initializers we want to
accept, with some sensible default (say 64 bytes?), so that we don't blow the
debug info size with multi-MB initializers, but for reasonably small things we
improve the debug info experience.  I'll implement something without --param
first and see how much it grows debug info on say cc1plus or libstdc++.
Note that we emit debug info for those vars anyway, just don't provide any
DW_AT_location/DW_AT_const_value currently, so ptype works, but print doesn't.

[Bug debug/55608] [4.6/4.7/4.8 Regression] Debug info quality regressions with file scope vars

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55608

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-06 14:11:59 UTC ---
Created attachment 28888
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28888
gcc48-pr55608.patch

Untested patch (which depends on the PR55395 fix).

With this patch, we emit debug info for most of the vars in:

static const char *a = "opq";
static const char b[8] = "rstuv";
static const char *c = b;
static const char *d = b + 3;
static const int e[] = { 1, 2, 3, 4 };
static int f[] = { 5, 6, 7 };
static const int *g = e;
static const int *h = e + 2;
static const int *i = f;
static const int *j = f + 2;

int
main ()
{
  const char *p = "abcd";
  const char *q = "efgh";
  const char r[] = "ijk\0lmn";
  const char *s = r;
  const char *t = b;
  const int *u = e;
  const int *v = e + 2;
  const int *w = f;
  const int *x = f + 2;
  return 0;
}

without it for none except for s.  What isn't handled at all is r (we'd need
some CDDCE? change, during gimplification the DECL_INITIAL of the automatic
variable is replaced with aggregate assignment to it, but then CDDCE just
removes all stmts referencing the var as dead, if we could figure out that the
var has been assigned just once by aggregate copy, we could restore its
DECL_INITIAL back and let dwarf2out do it's job), so DW_OP_GNU_implicit_pointer
emitted for s isn't very useful either.  Another not handled is v, for some
reason the ccp1 pass propagates
  v_8 = &MEM[(void *)&e + 8B];
  # DEBUG v => v_8
into
  # DEBUG v => &3
instead of
  # DEBUG v => &MEM[(void *)&e + 8B]
I would have expected.

And, on the GDB side we need some improvements too.
Surprisingly, DW_OP_GNU_implicit_pointer referencing DW_TAG_dwarf_procedure
with DW_AT_location of DW_OP_implicit_value works to some extent, but it would
be nice if where GDB normally prints 0xaddress "string" it could print
<synthetic pointer> "string".
(gdb) p a
$1 = <synthetic pointer>
(gdb) p a[0]
$2 = 111 'o'
(gdb) x/1s a
0x0: <Address 0x0 out of bounds>

It would be nice if also x/? could print the implicitly pointed memory.

p b works just fine, p c[0] doesn't, so apparently GDB doesn't handle if
DW_OP_GNU_implicit_pointer points to a DIE with DW_AT_const_value attribute
rather than DW_AT_location.

[Bug debug/55608] [4.6/4.7/4.8 Regression] Debug info quality regressions with file scope vars

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55608

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Target Milestone|---                         |4.6.4

[Bug debug/55608] [4.6/4.7/4.8/4.9 Regression] Debug info quality regressions with file scope vars

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55608

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
   Target Milestone|4.6.4                       |4.9.0
            Summary|[4.6/4.7/4.8 Regression]    |[4.6/4.7/4.8/4.9
                   |Debug info quality          |Regression] Debug info
                   |regressions with file scope |quality regressions with
                   |vars                        |file scope vars

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-11 15:55:17 UTC ---
Cary said on gcc-patches this is a stage1 material, so let's defer it for 4.9
then.

[Bug debug/55608] [4.6/4.7/4.8/4.9 Regression] Debug info quality regressions with file scope vars

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55608

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-21 20:03:19 UTC ---
Author: jakub
Date: Thu Mar 21 17:35:39 2013
New Revision: 196886

URL: http://gcc.gnu.org/viewcvs?rev=196886&root=gcc&view=rev
Log:
    PR debug/55608
    * dwarf2out.c (tree_add_const_value_attribute): Call ggc_free (array)
    on failure.
    (resolve_one_addr): Fail if referenced STRING_CST hasn't been written.
    (string_cst_pool_decl): New function.
    (optimize_one_addr_into_implicit_ptr): New function.
    (resolve_addr_in_expr): Optimize DWARF location expression
    DW_OP_addr DW_OP_stack_value where DW_OP_addr refers to some variable
    which doesn't live in memory, but has DW_AT_location or
    DW_AT_const_value, or refers to a string literal, into
    DW_OP_GNU_implicit_pointer.
    (optimize_location_into_implicit_ptr): New function.
    (resolve_addr): If removing DW_AT_location of a variable because
    it was DW_OP_addr of address of the variable, but the variable doesn't
    live in memory, try to emit const value attribute for the initializer.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dwarf2out.c

[Bug debug/55608] [4.7/4.8/4.9 Regression] Debug info quality regressions with file scope vars

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55608

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed on the trunk.  There are still a few cases we don't handle on
the GCC side, but for most we emit it right, and it would be nice if GDB
emitted
for something like
(gdb) p a
$1 = <synthetic pointer>
(gdb) p a[0]
$2 = 111 'o'
(gdb) p a[1]
$3 = 112 'p'
(gdb) p a[2]
$4 = 113 'q'
(gdb) p a[3]
$5 = 0 '\000'
for the first case when the synthetic pointer is pointer to chars and all the
chars till terminating '\0' are defined something like:
(gdb) p a
$1 = <synthetic pointer> "opq"

but I'd say we can close this now.