On Fri, Nov 21, 2008 at 06:51:26PM +0100, Joel Porquet wrote: > 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) ?
No, there's nothing wrong with this. You can even use multiple models in the same executable for the same symbol. The linker will take care of everything necessary. For instance, the executable's TLS block is at a fixed offset from the DTV pointer. If you're seeing a bug, then please give a test case that fails at runtime - there can always be bugs. But there is nothing wrong with the tests you've posted so far that I can see. > 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. Your conclusion does not follow from the evidence. __tls_get_addr takes a pointer to a {module, offset} pair. There's no dynamic relocation for the offset, but that's OK - the linker has calculated it at link time. Take a look at the contents of the GOT starting at 0x5ffe14b0 for four words. The second and fourth words will be the offsets. This is a global dynamic sequence, since it passes non-zero offsets to __tls_get_addr. -- Daniel Jacobowitz CodeSourcery