Re: A patch for pt.c

[Geoff Keating <geoffk at ozemail dot com dot au>]

> Date: Mon, 5 Jul 1999 10:54:30 -0700 (PDT)
> Cc: geoffk@ozemail.com.au, drepper@cygnus.com (Ulrich Drepper),
>         ian@cygnus.com (Ian Lance Taylor), egcs-patches@egcs.cygnus.com
> From: hjl@lucon.org (H.J. Lu)
> 
> > 
> > 
> > On Mon, 5 Jul 1999, Geoff Keating wrote:
> > 
> > > I suspect there is a (possibly machine-specific) bug in your ld; in
> > > fact, I would suspect the problem is in linking PIC code into
> > > executables.
> > 
> > When I originally looked at this using a different test case (G++ and some
> > templates) I found that you could only get it to happen reliably on intel,
> > sparc showed something similar and alpha appeared to work correctly. 
> > 
> 
> It is a very tricky bug. I don't think you will see it on machines
> with PIC as default. However, in my second testcase, you may see a

You mean, "you won't see it on alpha", since that is the only machine
which you mention which uses PIC as default.

> different bug where executable and DSO may have different values for
> the same symbol. The whole thing is due to the weak symbol handling.
> It is a known issue when DSO is involved. We had a lengthy discussion
> at the IA64 ABI committee. Basically, to get it right for C++ with
> DSO, we have to use weak for the same symbol in all cases. 
> 
> This patch to gcc may do the trick. It should work on all platforms.
> Please try to recompile gcc 2.95 and try again.

I'm confused.

In your testcase, you do this:

First, you build a shared object `libfoo.so', containing a non-weak symbol:

int deallocate = 0;

Next, you build two executables.  Each executable redefines the same
symbol, twice, as a weak symbol:

[in `main.c':]
#pragma weak deallocate
int deallocate = 0;

[in `bar.c':]
#pragma weak deallocate

int deallocate = 0;


Then you check that functions in 'main.c' and in 'bar.c' see the same
address of the symbol.  The link order is `libfoo.so main.o bar.o'.
The two testcases differ only in that `bar.c' is compiled PIC in one
of them.


Now, in this case the correct behaviour is always that the symbol seen
is the one in 'main.c', because executables override shared objects
and otherwise the first symbol in link order is the one that is
visible.  Both GNU 'ld' on powerpc-linux, and Solaris 'ld' on
sparc-solaris, agree with me on this (I just checked).

The effect of the '#pragma weak' here is that it suppresses what would
otherwise be a link error.  It has no other effect.

Again, ld.so has nothing to do with the result of the testcase; the
relocations should be bound inside the executable (except possibly on
alpha, where everything is PIC).

However, you should still use '#pragma weak' on objects like
'libfoo.o', because if you compiled it to a _static_ library, it could
cause a link error.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>