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