2008/11/20 Daniel Jacobowitz <[EMAIL PROTECTED]>:
> On Thu, Nov 20, 2008 at 05:28:16PM +0100, Joel Porquet wrote:
>> Gcc is using local-exec tls model instead of global-dynamic. The
>> option -fpie is supposed to act as -fpic though (dixit the manual).
>> Here is the first problem...
>
> Could you explain the problem with this?  The choice of local-exec vs
> global-dynamic does not affect whether code is position independent.

I agree that wether the code is pic or not and the tls model are quite
independent.
According to the manual, the default policy for TLS is affected by the
pic model though:

-ftls-model=model
...
          The default without -fpic is "initial-exec"; with -fpic the
default is "global-dynamic".

> It's a difference between linking an executable versus linking a
> shared library; this is one of the distinctions between -fpie and
> -fpic.

Yes for the linking stage but for the object compilation, -fpie should
be almost the same.

>> But then readelf tells me:
>>
>> Relocation section '.rel.dyn' at offset 0x3d4 contains 2 entries:
>>  Offset     Info    Type            Sym.Value  Sym. Name
>> 00000000  00000000 R_MIPS_NONE
>> 5ffe1460  00000026 R_MIPS_TLS_DTPMOD
>>
>> The symbol name is missing and most of all, the offset type is missing
>> too: there should be a R_MIPS_TLS_DTPREL type with the
>> R_MIPS_TLS_DTPMOD, since for each tls variable in global dynamic
>> model, tls_get_addr must receive the module index and the offset. Here
>> is the second problem...
>
> That's because this is the local dynamic model.

It could be but firstly when the global-dynamic model is specified one
should expect to get global-dynamic and not local-dynamic, and anyway
it is not local-dynamic.

Let's make the same test with two "global-dynamic" variables:

__thread int test_loc1 __attribute((tls_model("global-dynamic")));
__thread int test_loc2 __attribute((tls_model("global-dynamic")));

void func()
{
   test_loc1 = 2;
   test_loc2 = 3;
}

Which produces the following asm:

20:   8f990000        lw      t9,0(gp)
                       20: R_MIPS_CALL16       __tls_get_addr
 24:   27840000        addiu   a0,gp,0
                       24: R_MIPS_TLS_GD       test_loc1
 28:   0320f809        jalr    t9
 2c:   00000000        nop
 30:   8fbc0000        lw      gp,0(sp)
 34:   24030002        li      v1,2
 38:   8f990000        lw      t9,0(gp)
                       38: R_MIPS_CALL16       __tls_get_addr
 3c:   27840000        addiu   a0,gp,0
                       3c: R_MIPS_TLS_GD       test_loc2
 40:   0320f809        jalr    t9
 44:   ac430000        sw      v1,0(v0)
 48:   8fbf000c        lw      ra,12(sp)
 4c:   24030003        li      v1,3
 50:   8fbc0000        lw      gp,0(sp)
 54:   ac430000        sw      v1,0(v0)

It is the code for global-dynamic handling (and not local-dynamic).
Otherwise there would be some R_MIPS_TLS_DTPREL_*16 symbols and
anyway, R_MIPS_TLS_GD is the symbol for global-dynamic (it is named
R_MIPS_TLS_LDM for local-dynamic).

However, readelf shows, after linking:

Relocation section '.rel.dyn' at offset 0x3f4 contains 3 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000000  00000000 R_MIPS_NONE
5ffe14a0  00000026 R_MIPS_TLS_DTPMOD
5ffe14a8  00000026 R_MIPS_TLS_DTPMOD

Two R_MIPS_TLS_DTPREL are thus missing (at 5ffe14a4 and 5ffe14ac) .
And if we were really in local-dynamic, we would have only one
R_MIPS_TLS_DTPMOD.

Reply via email to