On Wed, Oct 19, 2011 at 9:47 PM, John David Anglin <dave.anglin@xxxxxxxx> wrote: > I looked at this a bit. The problem is legitimize_tls_address doesn't work > properly. First, GCC doesn't know that the libcall needs r26 and ret0 when the > __thread variable is an argument to a call. Secondly, the implementation of __tls_get_addr > clobbers some other call clobbered registers. I'm thinking the glibc implementation > might need to be in assembly language so that the clobbered registers are limited (i.e., > it needs to save registers). This all seems really ugly... > > The issues occur in generating PIC code. Yes, __tls_get_addr is a normal C function and follows normal function register usage. Why does __tls_get_addr need to be a special function? Almost all the targets in glibc-ports have C versions of __tls_get_addr. For example I notice that on Alpha the call to __tls_get_addr is *not* done via a emit_library_call_value, instead they use some emit_insn, emit_libcall_block and use_reg. So it looks like they tamper with the register usage via use_reg before the call to __tls_get_addr? Another example is Sparc which also uses a custom sequence and manipulates the used registers. I think our legitimize_tls_address needs to be rewritten to match something like what alpha or sparc has, otherwise we are going to run into trouble trying to get emit_library_call_value to work correctly. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
