[dmd-beta] dmd 1.070 and 2.055 beta

[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20110905/68a32c20/attachment-0001.html>