This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

MIPS : offset address in .rel.dyn for the different symbols may become the same


Hello.

I am using the MIPS toolchain as follows.

+ binutils 2.17.50.0.16.20070511
  - configured/builded with
    --host=i686-pc-linux-gnu 
    --target=mips-xxx-linux 
    --build=i686-pc-linux-gnu 

+ gcc 4.1.1
  - configured/builded with
     --host=mips-xxx-linux 
     --build=i686-pc-linux-gnu 
     --with-arch=mips2 

I believe I found the problem of the TLS relocation offset address, 
in elf binaries created by the procedure below.

I have no idea whether this is the issue of the linker, or the compiler,
or my procedure below , or else.

So if somebody has any information about this, would you please give
it to me ?

+ Three files which use the TLS, to create the shared library

/* --------  t0.c ------- */
#include <stdio.h>

__thread int __tsd_0_0 = 1 ;

void t0(void)
{
  printf("t0:0_0=%d\n",__tsd_0_0) ;
}


/* --------  t1.c ------- */
#include <stdio.h>

extern __thread int __tsd_0_0 ;
extern __thread int __tsd_2_0 ;
extern __thread int __tsd_2_1 ;

void t1(void)
{
  printf("t1:0_0=%d\n",__tsd_0_0) ;
  printf("t1:2_0=%d\n",__tsd_2_0) ;
  printf("t1:2_1=%d\n",__tsd_2_1) ;
}


/* --------- t2.c ----------*/
__thread int __tsd_2_0 = 2;
__thread int __tsd_2_1 = 3;

+ Building
----------

# mips-xxx-linux-gcc -Wall -O2 -fPIC -o t0.o -c t0.c
# mips-xxx-linux-gcc -Wall -O2 -fPIC -o t1.o -c t1.c
-ftls-model=initial-exec
# mips-xxx-linux-gcc -Wall -O2 -fPIC -o t2.o -c t2.c
# mips-xxx-linux-gcc -shared  -o libxxx.so t0.o t1.o t2.o

 - Note 
   - Only t1.c uses the -ftls-model=initial-exec option.
   - The link order to create this so should be t0.o,t1.o,t2.o .

+ Results of the readelf
------------------------

# mips-xxx-linux-readelf -r libxxx.so

Relocation section '.rel.dyn' at offset 0x5a0 contains 8 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000000  00000000 R_MIPS_NONE
00010990  00000003 R_MIPS_REL32
00010994  00000003 R_MIPS_REL32
000109e0  0000072f R_MIPS_TLS_TPREL3 00000008   __tsd_2_1 <<== (1)
000109d4  00000a2f R_MIPS_TLS_TPREL3 00000004   __tsd_2_0
000109d8  00000b26 R_MIPS_TLS_DTPMOD 00000000   __tsd_0_0
000109dc  00000b27 R_MIPS_TLS_DTPREL 00000000   __tsd_0_0
000109e0  00000b2f R_MIPS_TLS_TPREL3 00000000   __tsd_0_0 <<== (2)

The offset address in the relocation section of (1) and (2) are
the same , even if they are different symbols.
I believe those address are differnt from each other.

+ Running 
-----------
This may cause the unexpected result of accesing those TLS symbols,
like the samples below.


/* test program */
#include <stdio.h>

extern void t0(void) ;
extern void t1(void) ;

int main(void)
{
  //  t0() ;
  t1() ;
  return 0 ;
}

# mips-xxx-linux-gcc -o test test.o -L. -lxxx

# ./test
t1:0_0=616759300   
t1:2_0=2
t1:2_1=616759300

The result of reading the __tsd_0_0,__tsd_2_1 were incorrect,
unexpected ones.

The result should be as follows.

# ./test
t1:0_0=1
t1:2_0=2
t1:2_1=3

+ Note 
--------
- I used the -ftls-model=initial-exec option,only for t1.c
  without this option, this problem did not happen.

- I changed the link order to create the library as
  t2.o,t1.o,t0.o, (alternate order of above) I cound not see
  the duplication of the offset address, 
  and this problem did not happen.

  In both cases, the sample code above correctly worked as expected.

Thank you for your help.

-- Yuji


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