[dmd-beta] dmd 1.070 and 2.055 beta

[Rainer Schuetze]

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>