Re: [PATCH] PR63300 'const volatile' sometimes stripped in debug info.

[Mark Wielaard <mjw at redhat dot com>]

On Tue, Sep 23, 2014 at 05:12:12PM -0400, Jason Merrill wrote:
> On 09/23/2014 08:17 AM, Andreas Arnez wrote:
> >Without such handling there
> >are cases where more DIEs than necessary are created, e.g. if we have
> >the following types:
> >
> >some_base_t *const
> >some_base_t *volatile restrict
> >some_base_t *const volatile restrict
> >
> >Then the latter is based on the first instead of the second, although
> >this requires one more DIE.
> 
> I think the consistency may be important for sharing across translation
> units with type units.  If one TU bases cv on const and another on volatile,
> will the type signatures of a class that uses the cv variant match?

Interesting. I hadn't considered that the DWARF type signature computation
depended on the order of the qualifier type tags. But indeed it does.
It flattens the DIE tree and computes a checksum over the specific
order of the tags in that flattening.

For example with GCC 4.8.3 -gdwarf-4 -fdebug-types-section:

= t.c =

int a;
const int b;
volatile const c;

struct s
{
  const volatile int i;
} s;

The DIE chain for the s.i type comes out as:
DW_TAG_volatile_type -> DW_TAG_const_type -> DW_TAG_base_type

While for:

= t2.c =

int a;
volatile int b;
volatile const c;

struct s
{
  const volatile int i;
} s;

The DIE chain for the s.i type comes out as:
DW_TAG_const_type -> DW_TAG_volatile_type -> DW_TAG_base_type

So the type signatures for struct s come out differently
(0x8e43dfce8e4537d7 vs 0xbf7b9ea7d436700b)
Even though these are of course the same (language) type.
It is just a difference in DIE representation because DWARF
doesn't specify an ordering on the qualifier type tags.

But I think that is just an ambiguity in the DWARF spec sugestion for
the type signature computation. The result is just a missed oppertunity
for merging the debug-types for something which on a higher (language)
level looks like the same type. And for the default case (gcc doesn't
create type sections by default) the optimization is useful.

This should probably be fixed in the DWARF spec to make sure the
flattening algorithm describes an ordering to use for a chain of type
qualifier tags to use.

Or do you see a deeper problem than a missed optimization when debug
type sections are used?

Cheers,

Mark