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

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.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.