On November 15, 2009 07:42:46 Goetz Isenmann wrote:
I am still not sure, but the generated code might be ok
001e5565 <__hscore_get_errno>: 1e5565: 55 push %ebp 1e5566: 89 e5 mov %esp,%ebp 1e5568: 65 a1 00 00 00 00 mov %gs:0x0,%eax 1e556e: 8b 15 00 00 00 00 mov 0x0,%edx 1e5574: 8b 04 10 mov (%eax,%edx,1),%eax 1e5577: c9 leave 1e5578: c3 ret
The corresponding relocation info is
001e5570 R_386_TLS_IE errno
Not sure about DragonFly, but under Linux that would be the TLS initial- executable model . It is assuming that the TLS memory has already been allocated and is at the location pointed to by the word at %gs:0x0. The default when working with position-independent code is the dynamic model. It has to go through ___tls_get_addr in order to give the dynamic loader a chance to allocate the thread local storage memory if this is the first access The GNU variant of the code for this model is 0x00 leal x@tlsgd(,%ebx,1),%eax 0x07 call ___tls_get_addr@plt It returns the address in eax. The two relocation are R_386_TLS_GD to load eax to point to the GOT entry for the desired symbol and R_386_PLT32 for the call ___tls_get_addr. For more details on the four different modes (each one is a successive optimization of the general dynamic model for cases where the symbol is in the some shared object and/or the TLS memory is know to be allocated) http://people.redhat.com/drepper/tls.pdf (pages 19, 27, 36, and 44 give the code for the fully generic and each combination of the optimizations respectively). Under gcc you can specify the model via the "-ftls-model=<model>" option or on a per-identifier basis with __attribute__((tls_model("<model>"))). Besides changing what code is emitted, it sets the STATIC_TLS flag in the dynamic section to tell force allocation at thread creation if required. Cheers! -Tyson