Re: Fwd: Mips, -fpie and TLS management

["Joel Porquet" <joel dot porquet at gmail dot com>]

> This is one of the reasons that the generated code can only be used
> in executables.

Okay, I abdicate on this point.

Nevertheless, how could i have a coherent compilation concerning the
TLS management, if my executable needs dynamically libraries ? Aren't
the exec and dynamic models completely incompatible in the same
"whole" (eg one executable and shared libraries) ?

I mean you cannot access at the same storage, once with only a pointer
and an offset and once with a DTV.

So if my libraries are compiled with global-dynamic model but the
executable referring to them (and thus to their TLS data) is compiled
with initial-exec, don't we have a problem ?? The libraries will
access their data through a call to tls_get_addr with a module number
and an offset, while the executable will try to access the data
through a simple pointer and an offset.

>> 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.
>
> I don't remember what the deal is with the command line option, but
> I've run into that before.  The answer was, I think, that it is
> behaving as designed - but not intuitively.
>
> As for the model, you're right, it's not local dynamic.  It's global
> dynamic linked into an executable.  The linker has performed some
> optimization on your output file because it can determine the symbol
> binding at static link time.  There's no need for a dynamic relocation
> to calculate DTPREL when it's a link-time constant.

But there are no calculation. Here's the code for writing into two
global dynamic variable local to my exec:

__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;
}

And the compiled and linked code:

5ffe043c:       8f99802c        lw      t9,-32724(gp)
5ffe0440:       27848038        addiu   a0,gp,-32712
5ffe0444:       0320f809        jalr    t9
      #jump to tls_get_addr
5ffe0448:       00000000        nop
5ffe044c:       8fbc0000        lw      gp,0(sp)
5ffe0450:       24030002        li      v1,2
5ffe0454:       8f99802c        lw      t9,-32724(gp)
5ffe0458:       27848030        addiu   a0,gp,-32720
5ffe045c:       0320f809        jalr    t9
      #jump to tls_get_addr
5ffe0460:       ac430000        sw      v1,0(v0)
5ffe0464:       8fbf000c        lw      ra,12(sp)
5ffe0468:       24030003        li      v1,3
5ffe046c:       8fbc0000        lw      gp,0(sp)
5ffe0470:       ac430000        sw      v1,0(v0)

And the related reloc symbols are:
5ffe14b0  00000026 R_MIPS_TLS_DTPMOD
5ffe14b8  00000026 R_MIPS_TLS_DTPMOD

You can see that both the store instruction have not precalculated
offset but a 0 offset. It means that for accessing the two different
variables, the only way is to provide two different values for
R_MIPS_TLS_DTPMOD, which is incoherent. All the local variable for the
exec should be accessed via the same module number.
Well, I try but I really don't understand the "intended optimizations"
you mention. All I see is an attempt to make local-dynamic access (but
in a way that i don't understand and for which i cannot find any
documentation), although the attribute clearly specify
"global-dynamic".

> This is all very interesting, but you didn't answer my question: is
> this causing some problem, or just confusing?  These are all intended
> optimizations.

I cannot answer to your question. It is confusing for sure, and
personnally, I think there is a problem, but you seems to think
otherwise, so....