Re: _bfd_link_section_stabs: hash value weakness

[Ian Lance Taylor <ian at airs dot com>]

"Paul N. Hilfinger" <hilfingr@otisco.mckusick.com> writes:

> > This would seem to mean that two versions of language.h were replaced
> > with one version of language.h.  Presumably the types were supposed to
> > be the same.  Where's the problem? ...
> 
> > It seems to me that there must be something else going on.  
> 
> Yes, there is: the STABS data provides not just types, but also a mapping of 
> indices to types.  The latter mapping is used only while reading STABS data
> in its original textual form, and subsequently discarded.  Even if the
> type info is identical, if the mapping differs, the reading of subsequent 
> STABS data gets screwed up.

OK, I think I finally get it.  Sorry for taking so long.  In version 1
of language.h, the definition of ``function returning pointer to
struct value'' was already defined in some other header file.  In
version 2, that type is defined in language.h itself.  So the type
numbers are different.  And of course close inspection shows that
there are other minor but significant differences.  If the hash values
come out to be the same, then we have a problem.

In your example, the hash values happen to come out to be the same.
The minor differences cancel each other out.  Unfortunate but true.

We probably should use a better hash function, one which is less
likely to cause accidental duplication.  I don't think we should use
MD5, because the cost of the hash function is fairly significant in
profiles of linking large programs.

Ian