> On one hand, yes, it's a run-time property of the TLS symbol. On the other hand, the compiler selects the most efficient code to access a TLS variable based on what it knows about its location. By passing -ftls-model=initial-exec you're promising to the compiler that each TLS symbol will be in the static TLS block. That makes a lot of sense, but just bear with me a bit longer because I think we've hit the crux of what I'm trying to get at here. Let's say we are using the attribute form of tls-model=initial-exec. That means applying __attribute__((tls_model( initial-exec ))) to our TLS variable. Both export and import DSOs (libtls_export.so and libtls_import.so) will essentially be compiled with -ftls-model=initial-exec. Theory crafting time: Now, imagine (theoretically) that the DF_STATIC_TLS property were to ONLY be applied to DSOs that define/export at least one static TLS variable. That means libtls_export.so would have DF_STATIC_TLS while libtls_import.so would NOT have DF_STATIC_TLS. The compiler knows it can safely generate the efficient, offset-based retrieval routines for libtls_export.so (it can see the initial-exec attribute in the declaration of the TLS variable). However, since libtls_export.so is just a consumer, it doesn't really need to be tagged with DF_STATIC_TLS. The fact that libtls_import.so is tagged with DF_STATIC_TLS will ensure the TLS variable is placed in the static TLS segment (to the left of TP). libtls_export.so can now be dlopened at arbitrary points. I realize the attribute form of tls_model just ties into the command line form of the same setting, and the optimisation I've just described here cannot be safely achieved with the command line flag. But I'm curious to know if what I said makes sense. *Could* this have worked (ignoring this totally breaks ABI)? On a similar vein, is there any attribute/feature in gcc today that could have achieved the same effect? I know this is a weird use case, but I just want to see how far this can be pushed. Thanks again, Len
