This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: duplicate symbols on HP-PA

Partial success so far!

Yes, Jeff, the linker warning seems irrelevant.
I didn't know it was *that* common; I hadn't used -Wl,-v before.

On Thu, 16 Nov 2000, John David Anglin wrote:
> > 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.)

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

That is exactly what I meant by my `I will check' sentence.
I just had to wait for some recompilations for any link attempt to make sense.
(Used 4 different ABI's before...)

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

I think no linker would fold the actual data. Folding the weak functions would
just leave all but one copy of the data unused (which should have the same 
effect, though, except maybe for size).

My analysis is that weak does not work (reliably) on this platform:
I get multiple copies of weak functions (at least sometimes),
which want to use different copies of local static data.
So we need to fold the data in addition to (or instead of) the attempt
at folding the functions themselves.

As weak support is faulty, I meant I would only try exporting the `.comm' 
local static data (of 2.95.2), which is what I have done meanwhile. 

The HP linker *does* fold the local static *data* then.
I.e. my C++ (template class static member inline) function 
	foo_t& get_foo () { static foo_t foo; return foo; }
is still weak in many object files, 
and the linker still fails to fold them, 
but they all return a reference to the same data.

Sounds fine, but is not enough.

Unfortunately, each copy of the function still has its own local first-time
flag, so that the C++ object is constructed (and registered for destruction 
with atexit()) once per function copy called.
You could say, we still end up with several C++ objects instead of one, 
they just occupy the same space now 
(and therefore interfere badly with each other).

To get this right, the first-time flag needs to be folded as well.
I am currently trying this on top of the other change.
(Hacking the assembler output is more difficult here,
as the local flag symbol name is not mangled.)
But I am quite confident it will work. It must. ;-)

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

Or maybe no HP specific change at all, but fold function static data
on all platforms:

1) Keep treating the hp as supporting weak (if the assembler supports it
syntactically). In the cases it works, it conserves space for function text;
in the cases it doesn't, it doesn't hurt either, provided the following is
changed. (If weak can be fixed in binutils later, the compiler will not need 

2) On all platforms, and no matter whether they support weak or not,
fold function static data using (mangled) global common. On some platforms
this may save additional space. More importantly, on platforms without weak
support (or with broken weak support), only this gives the right semantics.

(I.e. we use weak, but don't rely on it.)

There are two potential issues with the second item: the danger of breaking
working ports and the danger of breaking ISO C++ conformance.

I think global common should always work on all platforms that support 
traditional C and/or Fortran. That is probably all potential GCC platforms 
at all, but it should be confirmed first by the maintainers of the existing 
backends. (Assuming the project is organised this way.)

Local names are not allowed to have "external linkage". I am no language
lawyer and have no C++ standard at hand. I only *assume* that mangling
can successfully hide the "linkage" from compliant C++ programs (and
useful non-compliant ones).

[To interest language lawyers in this thread, we would probably need to
change the `Subject:' line. They won't read further when they see this as an
hp specific issue, already being dealt with by the hp gurus.]



This email is confidential and intended solely for the use of the
individual to whom it is addressed.
Any views or opinions presented are solely those of the author
and do not necessarily represent those of Thyron Limited.
If you are not the intended recipient then please be advised
that you have received this email in error and that any use,
dissemination, forwarding, printing or copying of this email 
is strictly prohibited.
If you have received this email in error, please notify the 
Thyron IT Administrator on +44 (0)1923 236 050 or 
send an email to
Thank You

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]