------- Additional Comments From jakub at redhat dot com 2008-04-24 13:11 ------- The important thing is that executables and PIEs are always the first in the symbol search scope, so the linker can compute the offsets within the TLS block at runtime. For shared libraries you can't do that, as you don't know how big the executable or PIE's TLS block will be, what alignment will it need etc., so for those you need a runtime relocation.
If gcc on ppc/ppc64 reschedules insns and violates the TLS ABI, then it should be fixed. E.g. on i?86/x86_64 we use multiple asm insns in one define_insn to make sure that something that must be kept consecutive isn't scattered around. See e.g. tls_global_dynamic_64, tls_local_dynamic_base_64, tls_global_dynamic_32_gnu etc. in i386.md. But for fixing this particular bug you could perhaps leave out the local-dynamic and global-dynamic in the testcase, that was added just for completeness. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6443 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
