[Bug c++/33169] New: Compiler generates two different relocs for the same symbol

["atgraham at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

The compiler generates two different relocs for the same function call, which
causes the linker to get confused.

----- Input -----
#include "pthread.h"
#include <map>
#include <ext/pool_allocator.h>
typedef __gnu_cxx::__pool_alloc<std::pair<int const, int> > myalloc;
int main() {
  std::map<int, int, std::less<int>, myalloc> y;
  pthread_mutex_lock(0);
}
-----------------
build with:
  mipsel-linux-g++ -Os -fno-inline -c foo.cc
(No command line flags are required; they don't appear to make a difference,
but the examples here will reflect those above.)

In this code chunk, pthread_mutex_lock is called from two places.  The first is
from inside the allocator, the second is directly in main.  From the allocator,
a R_MIPS_GOT16/R_MIPS_LO16 reloc is generated.  From main(), a R_MIPS_CALL16
reloc is generated.

0000001c <__gthread_mutex_lock(pthread_mutex_t*)>:
  1c:   3c1c0000        lui     gp,0x0
                        1c: R_MIPS_HI16 _gp_disp
  20:   279c0000        addiu   gp,gp,0
                        20: R_MIPS_LO16 _gp_disp
  24:   0399e021        addu    gp,gp,t9
  28:   27bdffe0        addiu   sp,sp,-32
  2c:   afbf001c        sw      ra,28(sp)
  30:   afb00018        sw      s0,24(sp)
  34:   afbc0010        sw      gp,16(sp)
  38:   8f990000        lw      t9,0(gp)
                        38: R_MIPS_GOT16        .text
  3c:   27390000        addiu   t9,t9,0
                        3c: R_MIPS_LO16 .text
  40:   0320f809        jalr    t9
  44:   00808021        move    s0,a0
  48:   10400008        beqz    v0,6c
<__gthread_mutex_lock(pthread_mutex_t*)+0x
50>
  4c:   8fbc0010        lw      gp,16(sp)
  50:   8f990000        lw      t9,0(gp)
                        50: R_MIPS_GOT16        pthread_mutex_lock
  54:   02002021        move    a0,s0
  58:   8fbf001c        lw      ra,28(sp)
  5c:   8fb00018        lw      s0,24(sp)
  60:   27390000        addiu   t9,t9,0
                        60: R_MIPS_LO16 pthread_mutex_lock
  64:   03200008        jr      t9
  68:   27bd0020        addiu   sp,sp,32
  6c:   8fbf001c        lw      ra,28(sp)
  70:   8fb00018        lw      s0,24(sp)
  74:   03e00008        jr      ra
  78:   27bd0020        addiu   sp,sp,32

000000dc <main>:
  dc:   3c1c0000        lui     gp,0x0
                        dc: R_MIPS_HI16 _gp_disp
  e0:   279c0000        addiu   gp,gp,0
                        e0: R_MIPS_LO16 _gp_disp
  e4:   0399e021        addu    gp,gp,t9
  e8:   27bdffc8        addiu   sp,sp,-56
  ec:   afbf0034        sw      ra,52(sp)
  f0:   afb00030        sw      s0,48(sp)
  f4:   afbc0010        sw      gp,16(sp)
  f8:   8f990000        lw      t9,0(gp)
                        f8: R_MIPS_CALL16       std::map<int, int,
std::less<int
>, __gnu_cxx::__pool_alloc<std::pair<int const, int> > >::map()
  fc:   27b00018        addiu   s0,sp,24
 100:   0320f809        jalr    t9
 104:   02002021        move    a0,s0
 108:   8fbc0010        lw      gp,16(sp)
 10c:   8f990000        lw      t9,0(gp)
                        10c: R_MIPS_CALL16      pthread_mutex_lock
 110:   0320f809        jalr    t9
 114:   00002021        move    a0,zero
 118:   8fbc0010        lw      gp,16(sp)
 11c:   8f990000        lw      t9,0(gp)
                        11c: R_MIPS_CALL16      std::map<int, int,
std::less<int
>, __gnu_cxx::__pool_alloc<std::pair<int const, int> > >::~map()
 120:   0320f809        jalr    t9
 124:   02002021        move    a0,s0
 128:   8fbc0010        lw      gp,16(sp)
 12c:   8fbf0034        lw      ra,52(sp)
 130:   8fb00030        lw      s0,48(sp)
 134:   00001021        move    v0,zero
 138:   03e00008        jr      ra
 13c:   27bd0038        addiu   sp,sp,56

When the linker sees the R_MIPS_CALL16, it decides that a PLT entry should be
generated for the symbol, and thusly changes its object-modification behavior
for *all* invocations of the function.  The R_MIPS_CALL16 relocs are then
linked correctly, but the R_MIPS_GOT16 are linked incorrectly.

This is just as likely a bug in the linker as it is in the compiler, but gcc
4.0.0 (the only other version I have tested) doesn't have this problem.  It is
more consistent and generates R_MIPS_CALL16 in both cases.  If this is not a
bug in the compiler, I'll report to binutils.


-- 
           Summary: Compiler generates two different relocs for the same
                    symbol
           Product: gcc
           Version: 4.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: atgraham at gmail dot com
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mipsel-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33169