If I had my way

[Martin Nowak]

On Tue, 13 Dec 2011 15:53:22 +0100, Jacob Carlborg <doob at me.com> wrote:

> On 2011-12-13 15:15, Martin Nowak wrote:
>> TLS is not too difficult. We can either use bracketed sections again or
>> let the compiler emit small thunks that fetch the complete TLS section  
>> for
>> a executable/DSO. The important point is that fetching the TLS addresses
>> must
>> be done for each thread and from a local function within each DSO.
>> people.redhat.com/drepper/tls.pdf
>> My current approach is to register callbacks, and let the threads update
>> their ranges before GC.
>> Not sure, but it will probably causes eagerly allocation of the TLS  
>> blocks.
>
> Mac OS X doesn't support TLS (it does now in 10.7) so Walter rolled his  
> own implementation. I don't know how close that is to the EFL  
> implementation specified in the above link.
>
Which would open some room for hooks.

>> Some similar issues happen with the other section brackets (.deh,  
>> .minfo).
>> We need local symbols as brackets not global ones as they would collide.
>
> There is no need for brackets, they just cause problems. The correct way  
> to get section data on Mac OS X is to use the "getsectbynamefromheader"  
> function. You can have a look at my fork to see how its used.
>
Correctly used they don't and are a really cheap way to get the ranges.
Having an OS function to do this is nice but as far as I know it doesn't  
port
to ELF (without linking in some elf libs) while the C object ports to OSX.

> https://github.com/jacob-carlborg/druntime/blob/dylib/src/rt/memory.d#L318
>
>> I've tried several approaches.
>
> They way I've done it is to register a callback for the  
> "_dyld_register_func_for_add_image" function. The documentation  
> describes the function as:
>
> "When you call _dyld_register_func_for_add_image, the dynamic linker  
> runtime calls the specified callback (func) once for each of the images  
> that are currently loaded into the program. When a new image is added to  
> the program, your callback is called again with the mach_header for the  
> new image, and the virtual memory slide amount of the new image."
>
> In this callback I extract module infos, exception handling tables and  
> TLS data from the mach_header. This is now where the problem comes. I  
> need an associative array which maps mach_headers to a struct (or  
> similar) containing module infos, exception handling tables and TLS  
> data. But I don't have an associative array that works this earily in  
> the initialization phase of the runtime.
But it will get called from the thread that runs dlopen.
So how do you add/remove an EH table while another thread is
catching exceptions?

>
> The next problem is with accessing TLS. When a TLS variable is accessed  
> the compiler calls the ___tls_get_addr function, implemented in  
> druntime. This function receives the address and then converts it to TLS  
> using the TLS data bracketed in the object file. In this function I need  
> to somehow access the current object file/mach_header, then use this  
> mach_header to access the TLS data in the associative array mentioned  
> above.
Yeah, __tls_get_addr on OSX will require kind of a DSO specific handle or
call a DSO local function, i.e. C static.
>
> You can see my current implementation in my fork, everything below this  
> line:
>
> https://github.com/jacob-carlborg/druntime/blob/dylib/src/rt/memory.d#L267
>
> As you can see I don't have an associative array so the above currently  
> doesn't work.