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 .re l.dyn for the different symbols may become the same


Great! 
I checked that this patch fixed our issue.
Thank you very much.

-- Yuji
 
> "Yuji Ogihara" <Yuji.Ogihara@jp.sony.com> writes:
> > 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.
> 
> Thanks for the nicely-reduced testcase, it was a big help.
> 
> I can reproduce this with binutils CVS.  It's yet another 
> case in which we're getting confused about whether TLS 
> information is stored in the mips_got_entry structure or in 
> the symbol's hash table entry.  In the "master" GOT, we keep 
> entries for each input bfd distinct, so that we can easily 
> split the master GOT into multiple GOTs later on.  Thus if 
> one input bfd uses only IE accesses for a symbol, and another 
> uses only GD accesses, there will be two separate master GOT 
> entries, each with just one TLS type.  We store the accrued 
> TLS information in the hash table in such cases; it is the 
> hash table entry that tells us that both access models are needed.
> 
> The testcase exposes one situation in which we weren't making 
> the distinction correctly.  Please let me know if this patch 
> fixes things for you.
> 
> Richard
> 
> 
> bfd/
> 	* elfxx-mips.c (mips_elf_initialize_tls_index): When 
> processing a
> 	type (3) single-GOT entry, read tls_type from the hash 
> table entry
> 	rather than the GOT entry.
> 
> Index: bfd/elfxx-mips.c
> ===================================================================
> RCS file: /cvs/src/src/bfd/elfxx-mips.c,v retrieving revision 
> 1.206 diff -u -p -r1.206 elfxx-mips.c
> --- bfd/elfxx-mips.c	15 May 2007 13:55:54 -0000	1.206
> +++ bfd/elfxx-mips.c	29 May 2007 21:13:04 -0000
> @@ -3186,6 +3186,7 @@ mips_elf_initialize_tls_index (void **en
>    struct mips_got_entry *entry = (struct mips_got_entry *)*entryp;
>    struct mips_got_info *g = p;
>    bfd_vma next_index;
> +  unsigned char tls_type;
>  
>    /* We're only interested in TLS symbols.  */
>    if (entry->tls_type == 0)
> @@ -3201,6 +3202,7 @@ mips_elf_initialize_tls_index (void **en
>  	return 1;
>        entry->d.h->tls_type |= GOT_TLS_OFFSET_DONE;
>        entry->d.h->tls_got_offset = next_index;
> +      tls_type = entry->d.h->tls_type;
>      }
>    else
>      {
> @@ -3217,12 +3219,13 @@ mips_elf_initialize_tls_index (void **en
>  	  g->tls_ldm_offset = next_index;
>  	}
>        entry->gotidx = next_index;
> +      tls_type = entry->tls_type;
>      }
>  
>    /* Account for the entries we've just allocated.  */
> -  if (entry->tls_type & (GOT_TLS_GD | GOT_TLS_LDM))
> +  if (tls_type & (GOT_TLS_GD | GOT_TLS_LDM))
>      g->tls_assigned_gotno += 2;
> -  if (entry->tls_type & GOT_TLS_IE)
> +  if (tls_type & GOT_TLS_IE)
>      g->tls_assigned_gotno += 1;
>  
>    return 1;
> 


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