Am 05.09.2011 19:54, schrieb Rainer Schuetze:
>
> What OS are you running on?
>
> Your code works for me (XP SP3). Also Visual D works fine AFAICT (its a plugin DLL to VS).
>
>
> On 05.09.2011 19:17, S?nke Ludwig wrote:
>> Am 04.09.2011 06:48, schrieb Walter Bright:
>>> http://ftp.digitalmars.com/dmd1beta.zip
>>> http://ftp.digitalmars.com/dmd2beta.zip
>>> _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>> Has anything changed with regard to TLS?
>>
>> I'm getting OutOfMemoryErrors when accessing TLS arrays from within a DLL. Maybe the dll_fixTLS function in core.sys.windows.dll needs to be adjusted?
>>
>> ---
>> import std.c.windows.windows;
>> import core.sys.windows.dll;
>>
>> int[] s_arr;
>>
>> extern (Windows)
>> BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)  {
>> switch (ulReason) {
>> default: return false;
>> case DLL_PROCESS_ATTACH:
>>             if( !dll_process_attach( hInstance, true ) ) return false;
>>             s_arr ~= 0; // -> OutOfMemoryError
>> break;
>>     }
>> return true;
>> }
>> ---
>>
>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
Windows 7 x64 SP1... But it is more complicated than it seemed.

I had another file linked to the DLL that I thought had not effect. But actually it used a function from another DLL* that was linked in statically via passing a .lib file to the command line (along with the source files). The error does not occur if compiling and linking is done by separate invocations of dmd. Also commenting out all the lines that use a function from the external DLL fixes the problem.

(* that DLL is LLVM 2.9, so no D code inside)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110905/abc111d5/attachment.html>

On 05.09.2011 21:35, S?nke Ludwig wrote:
> Am 05.09.2011 19:54, schrieb Rainer Schuetze:
>>
>> What OS are you running on?
>>
>> Your code works for me (XP SP3). Also Visual D works fine AFAICT (its a plugin DLL to VS).
>>
> Windows 7 x64 SP1... But it is more complicated than it seemed.
>
> I had another file linked to the DLL that I thought had not effect. But actually it used a function from another DLL* that was linked in statically via passing a .lib file to the command line (along with the source files). The error does not occur if compiling and linking is done by separate invocations of dmd. Also commenting out all the lines that use a function from the external DLL fixes the problem.
>
> (* that DLL is LLVM 2.9, so no D code inside)
>
>

There might be issues if you are calling another DLL from inside the (non-shared) static constructors and that DLL also uses TLS. In DllMain(DLL_PROCESS_ATTACH), each existing thread is initialized by just swapping the TLS data of the DLL and then running the module initialization. So if another DLL is called, it will only see the TLS of the thread that called DllMain.

I don't think anything in this code has changes recently. Is this a regression from the last dmd version?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110905/d3eedd64/attachment.html>

Am 05.09.2011 23:53, schrieb Rainer Schuetze:
> On 05.09.2011 21:35, S?nke Ludwig wrote:
>> Am 05.09.2011 19:54, schrieb Rainer Schuetze:
>>>
>>> What OS are you running on?
>>>
>>> Your code works for me (XP SP3). Also Visual D works fine AFAICT (its a plugin DLL to VS).
>>>
>> Windows 7 x64 SP1... But it is more complicated than it seemed.
>>
>> I had another file linked to the DLL that I thought had not effect. But actually it used a function from another DLL* that was linked in statically via passing a .lib file to the command line (along with the source files). The error does not occur if compiling and linking is done by separate invocations of dmd. Also commenting out all the lines that use a function from the external DLL fixes the problem.
>>
>> (* that DLL is LLVM 2.9, so no D code inside)
>>
>>
>
> There might be issues if you are calling another DLL from inside the (non-shared) static constructors and that DLL also uses TLS. In DllMain(DLL_PROCESS_ATTACH), each existing thread is initialized by just swapping the TLS data of the DLL and then running the module initialization. So if another DLL is called, it will only see the TLS of the thread that called DllMain.
>
> I don't think anything in this code has changes recently. Is this a regression from the last dmd version?
>
>
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
Yes, it is a regression in the first beta. The new beta also has it.

In general, the LLVM DLL was not called at all before the error occurs, the pure fact that there was a dependency to it somewhere in the code causes the problem. Also, it doesn't matter whether the array is used somwhere inside of DllMain or later from within an exported function (this was actually the case before I tried to strip it down). There is just one static constructor in the code. Commenting it out does not affect the problem.

I now completely removed any other code and just put in one function call after the array appending line. Commenting out the llvm call will cause the array to be correctly initialized/referenced, otherwise it contains garbage in its ptr/length fields. (making it __gshared also fixes it)

The llvm.lib containing the llvm functions was generated from the dll using implib.

---
import std.c.windows.windows;
import core.sys.windows.dll;

import llvm.target;
int[] test;

extern (Windows)
BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
{
     switch (ulReason) {
         default: return false;
         case DLL_PROCESS_ATTACH:
             if( !dll_process_attach( hInstance, true ) ) return false;
             test ~= 1; // throws out of memory
             LLVMInitializeX86TargetInfo(); // commenting out this will
make it work
             break;
         case DLL_PROCESS_DETACH: dll_process_detach( hInstance, true );
break;
         case DLL_THREAD_ATTACH: dll_thread_attach( true, true ); break;
         case DLL_THREAD_DETACH: dll_thread_detach( true, true ); break;
     }
     return true;
}
---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110906/66106d98/attachment.html>

Could you get the druntime sources for the last dmd release, try those, and see if it works successfully?

On 9/5/2011 10:52 PM, S?nke Ludwig wrote:
> Am 05.09.2011 23:53, schrieb Rainer Schuetze:
>> On 05.09.2011 21:35, S?nke Ludwig wrote:
>>> Am 05.09.2011 19:54, schrieb Rainer Schuetze:
>>>>
>>>> What OS are you running on?
>>>>
>>>> Your code works for me (XP SP3). Also Visual D works fine AFAICT (its a plugin DLL to VS).
>>>>
>>> Windows 7 x64 SP1... But it is more complicated than it seemed.
>>>
>>> I had another file linked to the DLL that I thought had not effect. But actually it used a function from another DLL* that was linked in statically via passing a .lib file to the command line (along with the source files). The error does not occur if compiling and linking is done by separate invocations of dmd. Also commenting out all the lines that use a function from the external DLL fixes the problem.
>>>
>>> (* that DLL is LLVM 2.9, so no D code inside)
>>>
>>>
>>
>> There might be issues if you are calling another DLL from inside the (non-shared) static constructors and that DLL also uses TLS. In DllMain(DLL_PROCESS_ATTACH), each existing thread is initialized by just swapping the TLS data of the DLL and then running the module initialization. So if another DLL is called, it will only see the TLS of the thread that called DllMain.
>>
>> I don't think anything in this code has changes recently. Is this a regression from the last dmd version?
>>
>>
>>
>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
> Yes, it is a regression in the first beta. The new beta also has it.
>
> In general, the LLVM DLL was not called at all before the error occurs, the pure fact that there was a dependency to it somewhere in the code causes the problem. Also, it doesn't matter whether the array is used somwhere inside of DllMain or later from within an exported function (this was actually the case before I tried to strip it down). There is just one static constructor in the code. Commenting it out does not affect the problem.
>
> I now completely removed any other code and just put in one function call after the array appending line. Commenting out the llvm call will cause the array to be correctly initialized/referenced, otherwise it contains garbage in its ptr/length fields. (making it __gshared also fixes it)
>
> The llvm.lib containing the llvm functions was generated from the dll using implib.
>
> ---
> import std.c.windows.windows;
> import core.sys.windows.dll;
>
> import llvm.target;
> int[] test;
>
> extern (Windows)
> BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
> {
>     switch (ulReason) {
>         default: return false;
>         case DLL_PROCESS_ATTACH:
>             if( !dll_process_attach( hInstance, true ) ) return false;
>             test ~= 1; // throws out of memory
>             LLVMInitializeX86TargetInfo(); // commenting out this will make it
> work
>             break;
>         case DLL_PROCESS_DETACH: dll_process_detach( hInstance, true ); break;
>         case DLL_THREAD_ATTACH: dll_thread_attach( true, true ); break;
>         case DLL_THREAD_DETACH: dll_thread_detach( true, true ); break;
>     }
>     return true;
> }
> ---
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110905/68a32c20/attachment-0001.html>

With the call LLVMInitializeX86TargetInfo, the llvm DLL will be initialized before DllMain of your DLL is called. I could not find a matching DLL in the LLVM binary distribution. I guess you have built it yourself. Could you provide it for download somewhere?

On 06.09.2011 07:52, S?nke Ludwig wrote:
> Am 05.09.2011 23:53, schrieb Rainer Schuetze:
>> On 05.09.2011 21:35, S?nke Ludwig wrote:
>>> Am 05.09.2011 19:54, schrieb Rainer Schuetze:
>>>>
>>>> What OS are you running on?
>>>>
>>>> Your code works for me (XP SP3). Also Visual D works fine AFAICT (its a plugin DLL to VS).
>>>>
>>> Windows 7 x64 SP1... But it is more complicated than it seemed.
>>>
>>> I had another file linked to the DLL that I thought had not effect. But actually it used a function from another DLL* that was linked in statically via passing a .lib file to the command line (along with the source files). The error does not occur if compiling and linking is done by separate invocations of dmd. Also commenting out all the lines that use a function from the external DLL fixes the problem.
>>>
>>> (* that DLL is LLVM 2.9, so no D code inside)
>>>
>>>
>>
>> There might be issues if you are calling another DLL from inside the (non-shared) static constructors and that DLL also uses TLS. In DllMain(DLL_PROCESS_ATTACH), each existing thread is initialized by just swapping the TLS data of the DLL and then running the module initialization. So if another DLL is called, it will only see the TLS of the thread that called DllMain.
>>
>> I don't think anything in this code has changes recently. Is this a regression from the last dmd version?
>>
>>
>>
>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
> Yes, it is a regression in the first beta. The new beta also has it.
>
> In general, the LLVM DLL was not called at all before the error occurs, the pure fact that there was a dependency to it somewhere in the code causes the problem. Also, it doesn't matter whether the array is used somwhere inside of DllMain or later from within an exported function (this was actually the case before I tried to strip it down). There is just one static constructor in the code. Commenting it out does not affect the problem.
>
> I now completely removed any other code and just put in one function call after the array appending line. Commenting out the llvm call will cause the array to be correctly initialized/referenced, otherwise it contains garbage in its ptr/length fields. (making it __gshared also fixes it)
>
> The llvm.lib containing the llvm functions was generated from the dll using implib.
>
> ---
> import std.c.windows.windows;
> import core.sys.windows.dll;
>
> import llvm.target;
> int[] test;
>
> extern (Windows)
> BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
> {
>     switch (ulReason) {
>         default: return false;
>         case DLL_PROCESS_ATTACH:
>             if( !dll_process_attach( hInstance, true ) ) return false;
>             test ~= 1; // throws out of memory
>             LLVMInitializeX86TargetInfo(); // commenting out this will
> make it work
>             break;
>         case DLL_PROCESS_DETACH: dll_process_detach( hInstance, true
> ); break;
>         case DLL_THREAD_ATTACH: dll_thread_attach( true, true ); break;
>         case DLL_THREAD_DETACH: dll_thread_detach( true, true ); break;
>     }
>     return true;
> }
> ---
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110906/d35aa3fa/attachment.html>

It's getting more interesting... it works fine if the DLL is loaded from a D application - loading it from a C++ application (compiled with MSVS 2010) will fail with the exception.

I've uploaded a zip file [1] with the dllmain and the LLVM DLL, a D test program and the failing C++ project for VS 2010.

The build.cmd builds the DLL and the D test project using equivalent flags as for the full project, although the flags do not seem to matter.

I will try to see if the LLVM DLL can somehow be ruled out of the equation when I get some time later.

[1] http://netload.in/dateiuknS5rMdiL/linkproblem.zip.htm


Am 06.09.2011 09:14, schrieb Rainer Schuetze:
>
> With the call LLVMInitializeX86TargetInfo, the llvm DLL will be initialized before DllMain of your DLL is called. I could not find a matching DLL in the LLVM binary distribution. I guess you have built it yourself. Could you provide it for download somewhere?
>
> On 06.09.2011 07:52, S?nke Ludwig wrote:
>> Am 05.09.2011 23:53, schrieb Rainer Schuetze:
>>> On 05.09.2011 21:35, S?nke Ludwig wrote:
>>>> Am 05.09.2011 19:54, schrieb Rainer Schuetze:
>>>>>
>>>>> What OS are you running on?
>>>>>
>>>>> Your code works for me (XP SP3). Also Visual D works fine AFAICT
>>>>> (its a plugin DLL to VS).
>>>>>
>>>> Windows 7 x64 SP1... But it is more complicated than it seemed.
>>>>
>>>> I had another file linked to the DLL that I thought had not effect. But actually it used a function from another DLL* that was linked in statically via passing a .lib file to the command line (along with the source files). The error does not occur if compiling and linking is done by separate invocations of dmd. Also commenting out all the lines that use a function from the external DLL fixes the problem.
>>>>
>>>> (* that DLL is LLVM 2.9, so no D code inside)
>>>>
>>>>
>>>
>>> There might be issues if you are calling another DLL from inside the (non-shared) static constructors and that DLL also uses TLS. In DllMain(DLL_PROCESS_ATTACH), each existing thread is initialized by just swapping the TLS data of the DLL and then running the module initialization. So if another DLL is called, it will only see the TLS of the thread that called DllMain.
>>>
>>> I don't think anything in this code has changes recently. Is this a regression from the last dmd version?
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>> Yes, it is a regression in the first beta. The new beta also has it.
>>
>> In general, the LLVM DLL was not called at all before the error occurs, the pure fact that there was a dependency to it somewhere in the code causes the problem. Also, it doesn't matter whether the array is used somwhere inside of DllMain or later from within an exported function (this was actually the case before I tried to strip it down). There is just one static constructor in the code. Commenting it out does not affect the problem.
>>
>> I now completely removed any other code and just put in one function call after the array appending line. Commenting out the llvm call will cause the array to be correctly initialized/referenced, otherwise it contains garbage in its ptr/length fields. (making it __gshared also fixes it)
>>
>> The llvm.lib containing the llvm functions was generated from the dll using implib.
>>
>> ---
>> import std.c.windows.windows;
>> import core.sys.windows.dll;
>>
>> import llvm.target;
>> int[] test;
>>
>> extern (Windows)
>> BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
>> {
>>     switch (ulReason) {
>>         default: return false;
>>         case DLL_PROCESS_ATTACH:
>>             if( !dll_process_attach( hInstance, true ) ) return false;
>>             test ~= 1; // throws out of memory
>>             LLVMInitializeX86TargetInfo(); // commenting out this
>> will make it work
>>             break;
>>         case DLL_PROCESS_DETACH: dll_process_detach( hInstance, true
>> ); break;
>>         case DLL_THREAD_ATTACH: dll_thread_attach( true, true ); break;
>>         case DLL_THREAD_DETACH: dll_thread_detach( true, true ); break;
>>     }
>>     return true;
>> }
>> ---
>>
>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110906/d57b1702/attachment-0001.html>

I will try that in a few hours when I'm back from work.

Am 06.09.2011 08:16, schrieb Walter Bright:
> Could you get the druntime sources for the last dmd release, try those, and see if it works successfully?
>
> On 9/5/2011 10:52 PM, S?nke Ludwig wrote:
>> Am 05.09.2011 23:53, schrieb Rainer Schuetze:
>>> On 05.09.2011 21:35, S?nke Ludwig wrote:
>>>> Am 05.09.2011 19:54, schrieb Rainer Schuetze:
>>>>>
>>>>> What OS are you running on?
>>>>>
>>>>> Your code works for me (XP SP3). Also Visual D works fine AFAICT
>>>>> (its a plugin DLL to VS).
>>>>>
>>>> Windows 7 x64 SP1... But it is more complicated than it seemed.
>>>>
>>>> I had another file linked to the DLL that I thought had not effect. But actually it used a function from another DLL* that was linked in statically via passing a .lib file to the command line (along with the source files). The error does not occur if compiling and linking is done by separate invocations of dmd. Also commenting out all the lines that use a function from the external DLL fixes the problem.
>>>>
>>>> (* that DLL is LLVM 2.9, so no D code inside)
>>>>
>>>>
>>>
>>> There might be issues if you are calling another DLL from inside the (non-shared) static constructors and that DLL also uses TLS. In DllMain(DLL_PROCESS_ATTACH), each existing thread is initialized by just swapping the TLS data of the DLL and then running the module initialization. So if another DLL is called, it will only see the TLS of the thread that called DllMain.
>>>
>>> I don't think anything in this code has changes recently. Is this a regression from the last dmd version?
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>> Yes, it is a regression in the first beta. The new beta also has it.
>>
>> In general, the LLVM DLL was not called at all before the error occurs, the pure fact that there was a dependency to it somewhere in the code causes the problem. Also, it doesn't matter whether the array is used somwhere inside of DllMain or later from within an exported function (this was actually the case before I tried to strip it down). There is just one static constructor in the code. Commenting it out does not affect the problem.
>>
>> I now completely removed any other code and just put in one function call after the array appending line. Commenting out the llvm call will cause the array to be correctly initialized/referenced, otherwise it contains garbage in its ptr/length fields. (making it __gshared also fixes it)
>>
>> The llvm.lib containing the llvm functions was generated from the dll using implib.
>>
>> ---
>> import std.c.windows.windows;
>> import core.sys.windows.dll;
>>
>> import llvm.target;
>> int[] test;
>>
>> extern (Windows)
>> BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
>> {
>>     switch (ulReason) {
>>         default: return false;
>>         case DLL_PROCESS_ATTACH:
>>             if( !dll_process_attach( hInstance, true ) ) return false;
>>             test ~= 1; // throws out of memory
>>             LLVMInitializeX86TargetInfo(); // commenting out this
>> will make it work
>>             break;
>>         case DLL_PROCESS_DETACH: dll_process_detach( hInstance, true
>> ); break;
>>         case DLL_THREAD_ATTACH: dll_thread_attach( true, true ); break;
>>         case DLL_THREAD_DETACH: dll_thread_detach( true, true ); break;
>>     }
>>     return true;
>> }
>> ---
>>
>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110906/3969ddc7/attachment.html>

I can reproduce the issue on Win7 64, but not on XP. I have debugged it a little until I noticed that the generated code for TLS access seems broken:

dmd 2.054 generated this code for the append operation

  push        1
1000207D  mov         ecx,dword ptr [__tls_index (1006BF98h)]
10002083  mov         edx,dword ptr fs:[2Ch]
1000208A  mov         ebx,dword ptr [edx+ecx*4]
1000208D  lea         esi,[ebx+4]
10002093  push        esi
10002094  mov         eax,offset TypeInfo_Ai at __init (1005E9A0h)
10002099  push        eax
1000209A  call        __d_arrayappendcT (10004D68h)

while the beta generates

push        1
10002076  mov         ecx,dword ptr fs:[2Ch]
1000207D  mov         edx,dword ptr [ecx]
1000207F  lea         ebx,[edx+4]
10002085  push        ebx
10002086  mov         esi,offset TypeInfo_Ai at __init (10067A90h)
1000208B  push        esi
1000208C  call        __d_arrayappendcT (10004F9Ch)

so it completely ignores the tls_index. I guess it works on XP because there are less DLLs that use TLS, so the DLLs index ends up as 0.

Rainer

PS: one possibly bad thing: printf is imported from the LLVM DLL, not from the dmc runtime library. This might add more confusion.


On 06.09.2011 15:06, S?nke Ludwig wrote:
> I will try that in a few hours when I'm back from work.
>
> Am 06.09.2011 08:16, schrieb Walter Bright:
>> Could you get the druntime sources for the last dmd release, try those, and see if it works successfully?
>>
>> On 9/5/2011 10:52 PM, S?nke Ludwig wrote:
>>> Am 05.09.2011 23:53, schrieb Rainer Schuetze:
>>>> On 05.09.2011 21:35, S?nke Ludwig wrote:
>>>>> Am 05.09.2011 19:54, schrieb Rainer Schuetze:
>>>>>>
>>>>>> What OS are you running on?
>>>>>>
>>>>>> Your code works for me (XP SP3). Also Visual D works fine AFAICT (its a plugin DLL to VS).
>>>>>>
>>>>> Windows 7 x64 SP1... But it is more complicated than it seemed.
>>>>>
>>>>> I had another file linked to the DLL that I thought had not effect. But actually it used a function from another DLL* that was linked in statically via passing a .lib file to the command line (along with the source files). The error does not occur if compiling and linking is done by separate invocations of dmd. Also commenting out all the lines that use a function from the external DLL fixes the problem.
>>>>>
>>>>> (* that DLL is LLVM 2.9, so no D code inside)
>>>>>
>>>>>
>>>>
>>>> There might be issues if you are calling another DLL from inside the (non-shared) static constructors and that DLL also uses TLS. In DllMain(DLL_PROCESS_ATTACH), each existing thread is initialized by just swapping the TLS data of the DLL and then running the module initialization. So if another DLL is called, it will only see the TLS of the thread that called DllMain.
>>>>
>>>> I don't think anything in this code has changes recently. Is this a regression from the last dmd version?
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dmd-beta mailing list
>>>> dmd-beta at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>> Yes, it is a regression in the first beta. The new beta also has it.
>>>
>>> In general, the LLVM DLL was not called at all before the error occurs, the pure fact that there was a dependency to it somewhere in the code causes the problem. Also, it doesn't matter whether the array is used somwhere inside of DllMain or later from within an exported function (this was actually the case before I tried to strip it down). There is just one static constructor in the code. Commenting it out does not affect the problem.
>>>
>>> I now completely removed any other code and just put in one function call after the array appending line. Commenting out the llvm call will cause the array to be correctly initialized/referenced, otherwise it contains garbage in its ptr/length fields. (making it __gshared also fixes it)
>>>
>>> The llvm.lib containing the llvm functions was generated from the dll using implib.
>>>
>>> ---
>>> import std.c.windows.windows;
>>> import core.sys.windows.dll;
>>>
>>> import llvm.target;
>>> int[] test;
>>>
>>> extern (Windows)
>>> BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
>>> {
>>>     switch (ulReason) {
>>>         default: return false;
>>>         case DLL_PROCESS_ATTACH:
>>>             if( !dll_process_attach( hInstance, true ) ) return false;
>>>             test ~= 1; // throws out of memory
>>>             LLVMInitializeX86TargetInfo(); // commenting out this
>>> will make it work
>>>             break;
>>>         case DLL_PROCESS_DETACH: dll_process_detach( hInstance, true
>>> ); break;
>>>         case DLL_THREAD_ATTACH: dll_thread_attach( true, true ); break;
>>>         case DLL_THREAD_DETACH: dll_thread_detach( true, true ); break;
>>>     }
>>>     return true;
>>> }
>>> ---
>>>
>>>
>>> _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110906/4586715c/attachment.html>

On 9/6/2011 12:13 PM, Rainer Schuetze wrote:
>
> I can reproduce the issue on Win7 64, but not on XP. I have debugged it a little until I noticed that the generated code for TLS access seems broken:
>
> dmd 2.054 generated this code for the append operation
>
>  push        1
> 1000207D  mov         ecx,dword ptr [__tls_index (1006BF98h)]
> 10002083  mov         edx,dword ptr fs:[2Ch]
> 1000208A  mov         ebx,dword ptr [edx+ecx*4]
> 1000208D  lea         esi,[ebx+4]
> 10002093  push        esi
> 10002094  mov         eax,offset TypeInfo_Ai at __init (1005E9A0h)
> 10002099  push        eax
> 1000209A  call        __d_arrayappendcT (10004D68h)
>
> while the beta generates
>
> push        1
> 10002076  mov         ecx,dword ptr fs:[2Ch]
> 1000207D  mov         edx,dword ptr [ecx]
> 1000207F  lea         ebx,[edx+4]
> 10002085  push        ebx
> 10002086  mov         esi,offset TypeInfo_Ai at __init (10067A90h)
> 1000208B  push        esi
> 1000208C  call        __d_arrayappendcT (10004F9Ch)
>
> so it completely ignores the tls_index. I guess it works on XP because there are less DLLs that use TLS, so the DLLs index ends up as 0.
>

Very interesting. Can you provide the source code for that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110906/0a44bdff/attachment.html>

On 06.09.2011 22:45, Walter Bright wrote:
>
>
> On 9/6/2011 12:13 PM, Rainer Schuetze wrote:
>>
>> I can reproduce the issue on Win7 64, but not on XP. I have debugged it a little until I noticed that the generated code for TLS access seems broken:
>>
>> dmd 2.054 generated this code for the append operation
>>
>>  push        1
>> 1000207D  mov         ecx,dword ptr [__tls_index (1006BF98h)]
>> 10002083  mov         edx,dword ptr fs:[2Ch]
>> 1000208A  mov         ebx,dword ptr [edx+ecx*4]
>> 1000208D  lea         esi,[ebx+4]
>> 10002093  push        esi
>> 10002094  mov         eax,offset TypeInfo_Ai at __init (1005E9A0h)
>> 10002099  push        eax
>> 1000209A  call        __d_arrayappendcT (10004D68h)
>>
>> while the beta generates
>>
>> push        1
>> 10002076  mov         ecx,dword ptr fs:[2Ch]
>> 1000207D  mov         edx,dword ptr [ecx]
>> 1000207F  lea         ebx,[edx+4]
>> 10002085  push        ebx
>> 10002086  mov         esi,offset TypeInfo_Ai at __init (10067A90h)
>> 1000208B  push        esi
>> 1000208C  call        __d_arrayappendcT (10004F9Ch)
>>
>> so it completely ignores the tls_index. I guess it works on XP because there are less DLLs that use TLS, so the DLLs index ends up as 0.
>>
>
> Very interesting. Can you provide the source code for that?
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
it seems to happen with any code:

int x;

int main()
{
         return x;
}

generates

__Dmain comdat
         assume  CS:__Dmain
                 mov     EAX,FS:__tls_array
                 mov     ECX,[EAX]
                 mov     EAX,_D1m1xi[ECX]
                 ret
__Dmain ends

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110906/0a1702ea/attachment-0001.html>