Re: _bfd_link_section_stabs: hash value weakness

["Paul N. Hilfinger" <hilfingr at otisco dot mckusick dot com>]

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

> What is
> the actual problem that you are seeing?  

I have a variable declared

  struct value *v = allocate_value (type);

in the source for a file I am debugging.  I type

   (gdb) print v

and GDB responds with something like

   $42 = (void (*)()) 0xf00baa

It's easy to see why.  Consider what the rest of the stabs data (i.e.,
the stuff that DOESN'T come from this include file) looks like.  After
determining that it has already read in the .h file, and needn't do it
again for a certain file foo.o, the STABS consumer (in this case GDB),
still needs to read in the other STABS data from foo.o, which still
expects to refer to the types for this previously obtained .h file
using the same type indices as when foo.o was produced.

For example, the local variable declaration above got translated to STABS as 

   v:r(108,15)

The original .h information for file #108 in this particular .o file looked 
like this (from the message I sent you before):

1481   LSYM   0      0      00000000 73937  evaluate_exp:(108,13)=*(108,14)=f(108,15)=*(108,16)=xsvalue:,256,32;la_printchar:(108,17)=*(108,18)=f(0,19),288,32;\

That is, type #15 is a pointer to struct value (which is right).  In
the case I reported, the line above gets replaced by the corresponding
information from another .o's version of this include file:

1368   LSYM   0      0      00000000 68693  evaluate_exp:(100,13)=*(100,14)=f(93,5),256,32;la_printchar:(100,15)=*(100,16)=f(0,19),288,32;\

The information represented here represents the same types, but
assigns indices differently.  Unfortunately, it tells me that type #15
is void (*)(), which is wrong.  

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

Processing the EXCL reference is not the problem; it's processing the rest
of the .o file that makes (incorrect) references to the EXCLed file.  No
amount of intelligence can compensate for this: the original type
indexing is not derivable from the remaining information.

Paul