Re: [OT] Re: Windows DLLs and TLS
09.10.2012 0:51, Rainer Schuetze пишет: On 10/8/2012 8:13 PM, Denis Shelomovskij wrote: 08.10.2012 21:47, Rainer Schuetze пишет: Implicite TLS for dynamically loaded DLLs is not supported by XP or Sever 2003, so druntime contains a fix to simulate it. (The workaround has the drawback that the DLL cannot be unloaded anymore.) I'm just speculating, maybe something goes wrong with the tls_index variable, reading TLS variables would then access data from another DLL. Is your code doing callbacks into the host application in static initializers? With the XP workaround, the runtime initialization impersonates all threads that exist before loading the DLL, by switching the TLS-pointer array of the current thread, and that might be unexpected in a callback (but not doing this might produce even more unexpected results). Here you are! Just want to mention that I'm currently managed to publish my (continuation of your) TLS fix I did half a year before. It will finally solve this XP/Sever 2003 problem. It is available here but isn't finished now (fill be in few days): https://github.com/denis-sh/hooking/tree/master/tlsfixer Will this fix both issues (not being able to unload and that imperfect simulation of DLL_THREAD_ATTACH for existing threads)? That would be very cool. Unloading is fixed. I can't remember any problems with DLL_THREAD_ATTACH (but it was half year ago so I can miss something I did that time), can you concretize the problem? And it isn't related to D and D runtime (D is just an implementation language). It is assumed to fix everything launched on the system without administrator rights requirement (for office workers). I hope you aren't against it is based on your work? Sure, no problem. It's boost licensed, isn't it? ;-) Yes it is. But thanks anyway. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [OT] Re: Windows DLLs and TLS
On 10/9/2012 6:59 PM, Denis Shelomovskij wrote: 09.10.2012 0:51, Rainer Schuetze пишет: On 10/8/2012 8:13 PM, Denis Shelomovskij wrote: 08.10.2012 21:47, Rainer Schuetze пишет: Is your code doing callbacks into the host application in static initializers? With the XP workaround, the runtime initialization impersonates all threads that exist before loading the DLL, by switching the TLS-pointer array of the current thread, and that might be unexpected in a callback (but not doing this might produce even more unexpected results). Here you are! Just want to mention that I'm currently managed to publish my (continuation of your) TLS fix I did half a year before. It will finally solve this XP/Sever 2003 problem. It is available here but isn't finished now (fill be in few days): https://github.com/denis-sh/hooking/tree/master/tlsfixer Will this fix both issues (not being able to unload and that imperfect simulation of DLL_THREAD_ATTACH for existing threads)? That would be very cool. Unloading is fixed. I can't remember any problems with DLL_THREAD_ATTACH (but it was half year ago so I can miss something I did that time), can you concretize the problem? What I meant is the impersonation of existing threads from the thread that executes DLL_PROCESS_ATTACH to run the thread-local static constructors. Even though the TLS pointers are switched, they are still executed in the context of the current thread. Looking it up again, this is not an XP problem, those threads don't get a DLL_THREAD_ATTACH callback on newer systems aswell. So I guess we will have to live with possible issues, but you are supposed to not really do a lot in DllMain anyway.
[OT] Re: Windows DLLs and TLS
08.10.2012 21:47, Rainer Schuetze пишет: Implicite TLS for dynamically loaded DLLs is not supported by XP or Sever 2003, so druntime contains a fix to simulate it. (The workaround has the drawback that the DLL cannot be unloaded anymore.) I'm just speculating, maybe something goes wrong with the tls_index variable, reading TLS variables would then access data from another DLL. Is your code doing callbacks into the host application in static initializers? With the XP workaround, the runtime initialization impersonates all threads that exist before loading the DLL, by switching the TLS-pointer array of the current thread, and that might be unexpected in a callback (but not doing this might produce even more unexpected results). Here you are! Just want to mention that I'm currently managed to publish my (continuation of your) TLS fix I did half a year before. It will finally solve this XP/Sever 2003 problem. It is available here but isn't finished now (fill be in few days): https://github.com/denis-sh/hooking/tree/master/tlsfixer I hope you aren't against it is based on your work? -- Денис В. Шеломовский Denis V. Shelomovskij
Re: [OT] Re: Windows DLLs and TLS
On 10/8/2012 8:13 PM, Denis Shelomovskij wrote: 08.10.2012 21:47, Rainer Schuetze пишет: Implicite TLS for dynamically loaded DLLs is not supported by XP or Sever 2003, so druntime contains a fix to simulate it. (The workaround has the drawback that the DLL cannot be unloaded anymore.) I'm just speculating, maybe something goes wrong with the tls_index variable, reading TLS variables would then access data from another DLL. Is your code doing callbacks into the host application in static initializers? With the XP workaround, the runtime initialization impersonates all threads that exist before loading the DLL, by switching the TLS-pointer array of the current thread, and that might be unexpected in a callback (but not doing this might produce even more unexpected results). Here you are! Just want to mention that I'm currently managed to publish my (continuation of your) TLS fix I did half a year before. It will finally solve this XP/Sever 2003 problem. It is available here but isn't finished now (fill be in few days): https://github.com/denis-sh/hooking/tree/master/tlsfixer Will this fix both issues (not being able to unload and that imperfect simulation of DLL_THREAD_ATTACH for existing threads)? That would be very cool. I hope you aren't against it is based on your work? Sure, no problem. It's boost licensed, isn't it? ;-)
