Re: duplicate symbols on HP-PA

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> An implicit instantiation of a template class' static member function from
> two different translation units with identical actual template arguments
> exists twice in the executable with different local static data.
> (The function is a mere wrapper returning its local static data by reference.)
> The problem seems specific to the hpux/pa port.]
> 
> > Linking with `-Wl,-v' can give verbose info about
> > the linking process. 
> 
> It says (among lots of details)
> WARNING:  LIBRARY <thelibrary.a> HAS OVERFLOW SYMBOLS; USE CLEANRL

I have seen the message but don't know what it means.  It is not mentioned
in the HP lrom documentation.

> [Looking for the mangled name of one instantiation with nm, from binutils cvs]
> > > the following is common to both platforms (both using gcc 20001023 -O0 -g):
> > > - The function is defined twice in the archive library, 
> > >    but in different object file members.
> > > - Both definitions show up as `W' (with the address `00000000').
> > > - The function is not mentioned in the object file containing main 
> > >    (which is linked against the archive).
> It is called only indirectly by other member functions.
> 
> > > The linked executable, however, is very different.
> > >  uw7) The function is defined once (and with a nonzero address).
> > > hpux) The function is defined 4 times and with 4 different addresses
> > >       (all nonzero).
> and as 'T'.
> > >       Two versions are actually called, 
> > >       and they use different copies of local static variables.
> > 
> > Yuck.  This is the same kind of problem that I saw when a module was in
> > both libgcc and libstdc++.
> 
> Did you also get *more* copies from linking (4 out of 2), not just not fewer (1)?

I got one copy from libgcc and one from libstdc++ using a shared version
of libstdc++.

> Did you also observe that on HP-UX only?

That's all I was using.

> Did you also try linking with -v yourself and if so 
> did you get the same warning?

Yes.

> > I presume you don't want two copies of the local static data.
> That is actually the only problem I have. ;-)
> (Well, code bloat isn't nice either, but this one affects sheer correctness.)

This isn't very nice but I think if you only access local static data
from global procedures you will have unique data.

> I have looked at the assembler code generated meanwhile. It looks fine.
> No references to the local static data from outside the function
> (apart from a helper function that calls the destructor and that gets
> registered with atexit when construction succeeds - also fine).
> [I had suspected some inlining might have bypassed the weakness of the 
> function by accessing the data directly.]
> 
> > > So, apparently the folding of copies of identical instantiations of 
> > > function-static data seems to rely on the folding of the functions themselves,
> > > which fails here. 
> > 
> > It may be under hpux that such folding only occurs if there is a primary
> > definition that overrides the secondary (weak) definitions.
> 
> If weakness worked that way, an explicit instantiation should work around it,
> shouldn't it (assuming that it is not weak too, haven't checked that)? It doesn't.
> 
> > I haven't
> > been able to find any documention on this (see ld +help: Hidden Definitions
> > for a discussion of problems related to mixing shared and archive libs).
> 
> Nore have I. Here, `ld +help' only tells me that the relevant help is not 
> installed, and the manual page does not mention the word `weak'.

Weak symbols are implemented on the HP using what HP calls secondary
definitions (sdef).  The only reference that I can find to these symbols
is in the nm man page.

> I would assume the folding requires the pieces to be absolutely equal.
> But I have no idea at what granularity the comparison and folding 
> would happen. 
> Per function with its data? (But the data are in a different segment.)
> 
> I have tried compiling withoug -g, in case some debug info
> destroys equality between the two versions. It did not help.
> 
> Assuming the two (or four) copies were not identical
> (be it due to malformed application code or a compiler bug),
> then I would expect the folding attempt to produce an error
> rather than keeping duplicates (let alone produce more of them).
> (But I believe that is a QOI issue not a conformance issue
> from a C++ standard point of view.)
> Several copies of a global symbol with different addresses
> in an executable seems pretty odd to me.

Thinking about this, it may be that this will only work with shared
libraries.  The dynamic loader (shl_load) may have a more sophisticated
symbol binding procedure than ld.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)