On Wed, Oct 19, 2011 at 9:47 PM, John David Anglin <[email protected]> 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, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CADZpyizJx5fHwv5aHqoN-u1D95ph6dw8S+cAHKRS=mr6y0w...@mail.gmail.com
