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
[email protected]
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
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
