This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Fwd: Mips, -fpie and TLS management
2008/11/21 Daniel Jacobowitz <drow@false.org>:
> 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