<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Am 05.09.2011 23:53, schrieb Rainer Schuetze:
<blockquote cite="mid:4E6544EC.1080204@gmx.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 05.09.2011 21:35, Sönke Ludwig wrote:
<blockquote cite="mid:4E65247F.2090705@informatik.uni-luebeck.de"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Am 05.09.2011 19:54, schrieb Rainer Schuetze:
<blockquote cite="mid:4E650CBA.6080702@gmx.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<br>
What OS are you running on? <br>
<br>
Your code works for me (XP SP3). Also Visual D works fine
AFAICT (its a plugin DLL to VS).<br>
<br>
</blockquote>
Windows 7 x64 SP1... But it is more complicated than it seemed.<br>
<br>
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.<br>
<br>
(* that DLL is LLVM 2.9, so no D code inside)<br>
<br>
<br>
</blockquote>
<br>
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.<br>
<br>
I don't think anything in this code has changes recently. Is this
a regression from the last dmd version?<br>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
dmd-beta mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dmd-beta@puremagic.com">dmd-beta@puremagic.com</a>
<a class="moz-txt-link-freetext" href="http://lists.puremagic.com/mailman/listinfo/dmd-beta">http://lists.puremagic.com/mailman/listinfo/dmd-beta</a></pre>
</blockquote>
Yes, it is a regression in the first beta. The new beta also has it.<br>
<br>
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.<br>
<br>
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)<br>
<br>
The llvm.lib containing the llvm functions was generated from the
dll using implib.<br>
<br>
---<br>
import std.c.windows.windows;<br>
import core.sys.windows.dll;<br>
<br>
import llvm.target;<br>
int[] test;<br>
<br>
extern (Windows)<br>
BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved)
<br>
{ <br>
switch (ulReason) {<br>
default: return false;<br>
case DLL_PROCESS_ATTACH:<br>
if( !dll_process_attach( hInstance, true ) ) return
false;<br>
test ~= 1; // throws out of memory<br>
LLVMInitializeX86TargetInfo(); // commenting out this
will make it work<br>
break;<br>
case DLL_PROCESS_DETACH: dll_process_detach( hInstance, true
); break;<br>
case DLL_THREAD_ATTACH: dll_thread_attach( true, true );
break;<br>
case DLL_THREAD_DETACH: dll_thread_detach( true, true );
break;<br>
}<br>
return true;<br>
}<br>
---<br>
</body>
</html>