This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: stabs and N_EXCL
- To: mellon at pobox dot com
- Subject: Re: stabs and N_EXCL
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 4 May 2000 08:58:46 -0700
- CC: binutils at sourceware dot cygnus dot com
- References: <20000504123940.A47329@happy.checkpoint.com>
Date: Thu, 4 May 2000 12:39:40 +0000
From: Anatoly Vorobey <mellon@pobox.com>
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
suffice.
Ian