This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: stabs and N_EXCL

   Date: Thu, 4 May 2000 12:39:40 +0000
   From: Anatoly Vorobey <>

   Finally, the gist of the matter: it does in fact happen that two different
   sets of stabs for the same header file, which have different typenumbers,
   just happen to have the same hash value (because the fluctuations in typenumbers
   are small and cancel each other when added ASCIIly). The second instance of 
   the header will be deleted from the executable, but the first instance's 
   typenumber will not match the typenumbers demanded by definitions in the 
   rest of the second source file. I believe there is irreparable loss of 
   information at this point, i.e. a debugger simply cannot be smart enough 
   to link types correctly because the typenumbers don't match.

Interesting problem.

   I think it would be great if the hash computing algorithm could be made
   a bit smarter to make such coincidences completely improbable, and have
   some ideas to offer on how this could be done. Since the hash computing
   algorithm is completely internal to the linker, and is never used by
   debuggers, it doesn't seem overly important to avoid deviation from Sun's
   original algorithm.

I agree.  I can't see any reason that we must keep the same algorithm.

I suppose we could avoid such problems in general by using a CRC, or
an MD5 checksum.  It seems like overkill, though.  To avoid the
problem you describe, the hash function in bfd_hash_lookup should


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]