[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.