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