[dmd-beta] dmd 1.070 and 2.055 beta

[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

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