Porting to DragonFly BSD
twhitehead at gmail.com
Mon Nov 16 14:28:19 EST 2009
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 at tlsgd(,%ebx,1),%eax
0x07 call ___tls_get_addr at 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
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)
(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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091116/1532e317/attachment.bin
More information about the Glasgow-haskell-users