> 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....