Re: stabs and N_EXCL

[Anatoly Vorobey <mellon at pobox dot com>]

On Thu, May 04, 2000 at 08:58:46AM -0700, Ian Lance Taylor wrote:

>    From: Anatoly Vorobey <mellon@pobox.com>

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

Yes, it is.

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

Well, that is certainly one possible solution. However, the size of the
string to pass to bfd_hash_lookup() can potentially be quite large
(unlimited theoretically: it includes all the stabs strings of a
particular header file, nesting discounted), and generated on-the-fly
(because we still need to weed out filenumbers to achieve reasonable
number of matches). I don't know if there are potential memory problems
with using bfd_hash_lookup() with strings that large (and keeping all
of them in memory at once until the end of the scan) -- I've no idea
about binutils' memory usage patterns and haven't really inspected
bfd source except for this particular file.

The other solution is a CRT function of some sort, which would accept
a string and return an intermediate CRC value; the main loop will
call it repeatedly for each stabs string, after "smartly" stripping
some information from it, and then use the final CRC value as the hash.

What does "smartly" mean? Sun's idea of just losing the filenumbers
will probably work (because we'll be using a real CRC instead of adding
chars), but it's not ideal: because of the matter of using "foreign"
filenumbers that I described, the typenumbers of such "foreign" pairs
are also irrelevant for the purpose of matching two include instances
of the same header file. I.e. the best idea seems, to me, to be
the following: keep track of header file number (inside the current
object file), and when scanning a stabs string of a header file,
weed out *all* filenumbers, *and* typenumbers of the pairs with
"foreign" filenumbers not matching the current header number.

What do you think?

-- 
Anatoly Vorobey,
mellon@pobox.com http://pobox.com/~mellon/
"Angels can fly because they take themselves lightly" - G.K.Chesterton