Re: duplicate symbols on HP-PA

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

> > Yes, this is another approach.  I don't know if anyone has tried it to see
> > if HP's linker supports it.
> 
> (If not, it could not support traditional C and Fortran either, 
> as they use common symbols too. Or did I get you wrong?)
> 
> Actually, that is what 2.95.2 (no weak support on hppa) seems to try. It emits
> 
>         .SPACE $PRIVATE$
>         .SUBSPA $BSS$
> <mangled_scope_indicator>$<local_var_name>       .comm 12
> 
> But doesn't it need an `.EXPORT' directive to be shared with other compilation units?
> (I suppose $PRIVATE$ means privately mapped vmem, rather than local to comp unit.)
> 
> I have checked on sparc-solaris2.8/2.95.2. It is "local common" there too,
>         .local  <var>.<counter>
>         .common <var>.<counter>,12,4
> which seems equally wrong.
> But then, the functions are weak and only one copy with its local data survives, so the
> semantics are correct anyway.
> 
> "local common" is a strange concept to me, especially for C++ with its One Definition Rule.
> Just as if the compiler did not trust itself to issue one definition.
> Or is "common" a mistaken attempt here at folding non-locally?
> 
> [The following relates to hpux10.20/gcc_ss_20001023.
> When I wrote it, I did not realise it did not apply to hpux10.20/2.95.2.]
> >   > In the case of my problem, the functions were emitted (no inlining, -O0)
> >   > multiply in different translation units and as weak, each with their local
> >   > static data as local rather than weak or common.  Common should have worked
> 
> The CVS version emits
>         .SPACE $PRIVATE$
>         .SUBSPA $BSS$
>         .align 4
> <local_var_name>___<disambiguating_counter>
>         .block 12
> 
> No `.EXPORT' or `.weak' for the (in C++) local static variable.
> So the symbol is still local, but no longer common.
> 
> > That sounds like a bug to me.  Probably in the compiler itself since it seems
> > to me it should have arranged for the local data to be weak or common.
> 
> It seems that if weak is supported, neither 2.95.2 nor cvs fold local static data,
> but rely on only one copy being used due to the functions themselves being weak.
> That seems to work on solaris and in the majority of cases even on hp-ux.
> 
> I think it would be safer to make the data weak or common and may even save bss space.
> I will check if non-local common works around the apparent HP linker bug with 2.95.2.
> (Slow machine, etc.)
> If it does, maybe the PA should be treated again as not supporting weak symbols (correctly),
> and the same change (conceptually) can fix 2.95.2 and current cvs.

Marco,

Why don't you try making some of the local data weak or put it into global
common by hacking the assembler output.  Then see if the linker does the
right thing.  This will give an approach to resolve the problem under hpux.
It seems obvious now that just making a function weak is not sufficient
for the HP linker to fold the static data associated with it.

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