Re: _bfd_link_section_stabs: hash value weakness

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

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

> >> I recently encountered a case (on Linux) in which
> >> STABS data in several .o files for a certain header file were
> >> improperly merged in the executable.  That is, the version of the
> >> STABS data for one include file from one .o file was removed, and
> >> replaced with an EXCL reference to the STABS data for the same include
> >> file from another .o file, even though the two versions were not, in
> >> fact identical (specifically, the type indices did not quite agree).
> 
> >This normally only happens when you're doing something odd, like using
> >the same name for two different objects.  Can you describe the failure
> >in more detail?
> 
> Sure.  I encountered the problem while debugging a version of GDB.
> The include file language.h appears in numerous .o files.  I've
> appended the "colliding" stabs for language.h from two of the .o
> files.  I used a simple Emacs script to compute the hash values, and
> did indeed get the same value for each.  Notice the departure at about
> type index 15.

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?

That is, you said the problem was that stabs data for a certain header
file was improperly merged.  But the header file language.h should
always have had the same debugging information.  So how could a merge
of two different inclusions of language.h be improper?

It seems to me that there must be something else going on.  What is
the actual problem that you are seeing?  It's certainly true that the
debugger needs to handle merged header files in an intelligent
fashion--in particular, when processing an EXCL reference, you have to
process the referenced header file in its own context, not in the
current context.

> You don't say?  Well, is there any bar to substituting a slightly juicier 
> algorithm?  I gather that the particular value fields chosen are arbitrary.

I can't think of any barrier to a different algorithm.

Ian