2008/11/21 Daniel Jacobowitz <[EMAIL PROTECTED]>: > 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.
I didn't understand the fact that the TLS structure was independent of the way of accessing it (through models). > 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. I think there's no bug so far, I was mistaken. >> And the related reloc symbols are: >> 5ffe14b0 00000026 R_MIPS_TLS_DTPMOD >> 5ffe14b8 00000026 R_MIPS_TLS_DTPMOD Still, is R_MIPS_TLS_DTPMOD a correct symbol ? In the document you wrote about NPTL for mips (http://www.linux-mips.org/wiki/NPTL), there's no such relocation symbol: just R_MIPS_TLS_DTPMOD32 and R_MIPS_TLS_DTPMOD64. > 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. Indeed, the GOT seems to be already filled with the right offset, you were right. However the values are just a bit weird: 5ffe14b0: 00000000 nop 5ffe14b4: ffff8004 sdc3 $31,-32764(ra) 5ffe14b8: 00000000 nop 5ffe14bc: ffff8000 sdc3 $31,-32768(ra) We can see that the offsets are prefixed by ffff8. Why is that? Indeed, I guess that if the __tls_get_addr function is written in C, it forces to mask the value. Anyway, thanks for the answers, it did really help me, Joel
