Re: R_PPC_LOCAL24PC c++ linking problems with current binutils

[Geoff Keating <geoffk@ozemail.com.au>]

> From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> Date: Tue, 20 Jul 1999 00:07:53 +0200
> Cc: drow@false.org, geoffk@ozemail.com.au
> 
> Hi,
> 
> linking this little program currently fails on Linux/PPC, glibc-2.1:
> 
> mmaptest.cc:
> #include <string>
> class FileFd
> {
> public:
>    int iFd;
>    unsigned long Flags;
>    string FileName;
> 
> 
>    FileFd(int Fd,bool) : iFd(Fd), Flags(0) {};
>    virtual ~FileFd();
> };
> 
> 
> Compiling with c++ -o mmaptest.so -fPIC -shared mmaptest.cc gives:
> mmaptest.o: In function `__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned int, int &)':
> mmaptest.o(.__default_alloc_template<true, 0>::gnu.linkonce.t._S_chunk_alloc(unsigned int, int &)+0x234): undefined reference to `__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned int, int &)'
> mmaptest.o(.__default_alloc_template<true, 0>::gnu.linkonce.t._S_chunk_alloc(unsigned int, int &)+0x2a8): undefined reference to `__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned int, int &)'
> collect2: ld returned 1 exit status

OK, I see it.

The problem is that the following is happening:

1. g++ is defining the symbol 
 '__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned int, int &)'
   (in demangled form, which I'll just call `...' from now on :-)
   weak in a linkonce section.
2. In libstdc++.so, the symbol is not defined weak.
3. In the same linkonce section, there is 'bl ...@local'.  The @local
   is because it's a recursive call.
4. ld finds the strong definition, in the shared object.
5. The symbol is not therefore defined locally, and linking fails.
  
I assume ld is correct in emitting the linkonce section even though
it will actually be using the shared object symbol.  I may be wrong.
Certainly it doesn't seem to make much sense to do this.

Other fixes would be:
(i) define the libstdc++ symbol weak, and/or
(ii) don't use @local on weak symbols and/or 
(iii) make @local relocs point to the symbol defined in this object
whether or not there is a stronger definition elsewhere.

(ii) implies that it is not legal to have a weak nested procedure (at
present the register used for the static chain conflicts with
registers clobbered in the PLT), but I'm not sure this makes sense
anyway.

(iii) might be hard.  It means we have to keep track of multiple
symbol definitions in ld.  It is probably also the correct solution
:-(.

Note that it is not valid to just ignore the @local, because calling
through the PLT is allowed to trash certain registers and @local is
not.

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