Re: [PATCH 1/6] RTL & dwarf2out changes

[Cary Coutant <ccoutant at google dot com>]

>> In the case of loc_checksum(), we're tied to MD5 by the DWARF
>> standard. Otherwise, we could just rewrite it to use inchash
>> throughout.
>
> I'm not sure I understand the motivation. If gcc hashes in
> gcc specific stuff (and this hash, even before my changes is)
> then the output can never be re-created by anything but gcc.
>
> If the standard just wants a well hashed number at the end
> then any good hash should do.

It's complicated. The DWARF standard specifies how the signature for a
type unit (-fdebug-types-section) is computed, using MD5. There are
occasional location expressions in a type unit, but the only ones we
should see when computing a type signature are special-cased, and we
should never actually get to where hash_loc_operands() is called. If
one does slip through, it's not fatal -- we'll just generate a type
signature that doesn't conform to the standard, and we may miss an
opportunity for link-time type de-duplication.

For both -feliminate-dwarf2-dups and -gsplit-dwarf, though, we also
compute DIE signatures using the same code, and in these cases, we may
see location expressions that need hash_loc_operands(). These
signatures are not specified by the DWARF standard, so it's reasonable
(IMO) to reuse the existing hashing routine in that case. These
signatures are used for de-duplication, for fast lookup, and for
disambiguation where two CUs have the same DW_AT_name, so the loss of
information is not critical.

> I haven't checked it for this case, but if the hashing shows
> up in profiles it may be worth using a faster but non secure
> hash.
>
> Anyways I can drop the comment if you don't agree with it.

Thanks, please do. It does make sense, even if there's a theoretically
better way to do it.

-cary